See the api divide wouldn't matter if the runtimes were merged (this actually happened, you can still use Tango today if you like) since you'd just import the o

See the api divide wouldn't matter if the runtimes were merged (this actually happened, you can still use Tango today if you like) since you'd just import the other modules and have them side by side. Sure some libs might depend on std.socket and others on tango.socket, but that's not a huge problem since they can exist side-by-side. You might just need an adapter if you wanted to pass a socket from one lib to another that uses the different thing. Slight hassle but totally solvable. But with the incompatible language runtime components, you couldn't merge the user level libs either. The base Object and Exception classes worked one way in one lib but another in the other and both used the same underlying function names leading to a linker conflict. The user-level namespaces in D are always isolated to modules, but this low level language runtime is global. That was solved when the Tango requirements got merged upstream.