To quote GCC's help:
-Wshadow
Warn whenever a local variable or type declaration shadows another variable, parameter, type, class member (in C++), or instance variable (in Objective-C) or whenever a built-in function is shadowed. Note that in C++, the compiler warns if a local variable shadows an explicit typedef, but not if it shadows a struct/class/enum. If this warning is enabled, it includes also all instances of local shadowing. This means that -Wno-shadow=local and -Wno-shadow=compatible-local are ignored when -Wshadow is used. Same as -Wshadow=global.
Ok, I've been programming for over 40 years and this is the third time I came across the term "shadow" to refer to masking but, fair enough, to my surprise, variable shadowing is a thing.
I think we can agree that GCC is considered a "mainstream compiler"? 
Yes, we can agree to that.
Not really your fault, but to be fair, it's a bad example, cause as far as the implementation in FPC is concerned the parameter and the locals are different symbol tables and the compiler actively needs to check that an identifier inserted into the local symbol table isn't conflicting with one in the parameter symbol table.
How FPC deals with its symbol tables is completely irrelevant. What's relevant is that the parameters and the locals are in the same scope. Slice it however you like but THAT is a fact and, if you compile that, FPC correctly claims there is a duplicate identifier. Therefore, regardless of how FPC fiddles with its symbols tables, it reaches the correct conclusion: duplicate identifier, which can only happen when two identifiers are in the same scope.
Then please take your grievances up with the developers at Borland, because Delphi is where this behaviour originates and it is implemented in FPC to follow that behaviour:
You're right, I just tested it with Delphi 2 and it behaves as you stated. Another "breakthrough" from the folks that contributed writable constants to computer science.
Oh, and just for the sake of it, replacing the with-statement with the following:
Will result in this output:
2
2
I tried it because I had to see it to believe it and, you're right, that's the output. It's _appalling_. oh well... I wonder what N. Wirth would say if he saw this stuff.
One thing you are completely right about, I cannot put the blame on FPC for this disgrace, Delphi initiated it.
@BrunoK,
it would be something like this (untested because I cannot test it):
{$define LeftPad:=TKMemoParagraph(KMemo1.Blocks[ABlockNo]).Parastyle.LeftPadding}
and, IMO, it would be better to name the macro "LeftPadding" instead of "LeftPad" as this would make it more evident that the field being referenced is "LeftPadding".