Maybe renaming sysml to syml11 would not bring much indeed and could harm cherry-picking. I have no strong opinion about that.
But putting the new stuff in sysml14 could still make sense to avoid confusion.
As for Java namespaces, some more arguments in favor of *not* using a new Java namespace:
-It would probably be quite cheap to get the "old" BDD & IBD editors up-and-running again very quickly on top of SysML 1.4,
for the subset of SysML 1.4 (including deprecated stuff) corresponding to SysML 1.1.
Basically, only support for Unit and Dimension would have to be redone to use the new Unit & QuantityKind predefined blocks, and handling of conjugated ports would have to be aligned with UML 2.5.
The rest should work almost as-is.
This would allow to decouple SysML upgrade and editor technology upgrade.
-We do have quite a lot of edit helper advices for restricting SysML to our particular usage context and to maintain complex inter-dependent model subsets consistent.
During the migration/evaluation phase, we would have to duplicate them all and maintain both sets until we decide which version we will use for our version based on Mars.
As for (semantic) migration, it seems to me that the hardest part of the work is migrating flow ports & flow spec to use the new idioms, but since those concepts are supported as deprecated, there is no obligation to do that at load time
(and probably some wizard to help to migrate interactively after the fact would be better anyway, to not force migration away of those deprecated concepts if not desired). So I don't think the risk is big on that subject.