It won't be fully compatible anyway. E.g. unit Contnrs might just as well be placed in FCL.Contnrs instead of System.Contnrs (I'm not saying that it will be, but it's at least a possibility). And the LCL units on the other hand will very likely use LCL as prefix instead of VCL.
I surely hope not
For units that are part of the FPC distribution it might indeed be less likely that they'll have a different namespace, but I already know that dynamic packages won't be compatible, because there I'll favor maintainability before compatibility.
However, for example, you can use "System.Delete()" to execute a procedure if you already have a "Delete()" procedure in your application. It's a little namespace.
It's the “namespace” provided by the
System unit which is automatically used in every unit that isn't the
System unit.
I'd suggest that any departure from this which breaks compatibility with older FPC versions would be a very bad idea.
If we had to vote between keeping FPC compatible with both itself and older versions of Delphi, versus breaking compatibility in the name of chasing enhancements added to Delphi in its dotage, I'd be firmly on the side of tradition.
Once units are namespaced (and assuming that their base name stays the same) you can simply use the already existing
-FN option to define default namespaces. E.g.
-FNSystem with a unit
Classes will lead to the compiler looking for both
System.Classes and
Classes. So you can keep the source the same, but just adjust the compilation parameters.