> Also someone might want to use both modules (e.g. to use some kind of > a transition process). That technique would make this impossible.
If you call it another module name (say exp.process), then: A) you would not be able to test how the rest of phobos interacts with the new std.process unless you also temporarily changed the source files in phobos to include exp.process instead of std.process (messy). B) That could also lead to duplicate extern(C) symbols being defined in both modules. C) you would end up with the same situation that led to javax described above by others: significant amounts of code may start importing exp.process to the point where it's too late to change it back to std.process. ---- In what I proposed, the source never needs to change, only compile flags to specify order of imports. But to answer your concern, if you really want to temporarily import 2 versions of process.d to coexist and be co-importable, you can simply mixin-string-import experimental/std/experimental_std_process_version_3.d from a differently named module (say, std.process2), see my point B in proposal, although that shouldn't be the common use case. note: I just forgot to mention in the proposal that the 'module std.process;' declaration should be commented out from the implementation file experimental/std/experimental_std_process_version_3.d (which makes this module swapping possible).
