Yeah, me too. To be clear, this is not a “dumb” company. It’s very successful, with a market cap in the hundreds of billions and full of smart people. But a very good Julia programmer that I know just left the company for a smaller one precisely because of those stupid policies.
As for the upgrade to Julia 2, maybe it’s not necessary to ponder too much on hypothetical scenarios. Making predictions is hard. Especially about the future. Once Julia 2 has been released, we’ll find out if packages are upgraded or not, and if they are not, then we will be able to find out why just by asking the maintainers directly.
Old versions of packages don’t cease to exist just because new versions are released for Julia 2. Users who are conservative and don’t want to upgrade can keep using older versions of packages; there can even continue to be bug fix releases, and if a company depends on an older version, it may behoove them to help make those releases. New features, however, should get added to the latest Julia 2 version of a package. This encourages users to upgrade if they need new features or packages that only exist for Julia 2 which creates a strong incentive for users to switch.
If it’s easy to call new packages from Julia 1, then there’s zero incentive for users—who are generally less proactive than package maintainers—to upgrade anything: they can just leave their applications running Julia 1 and use new packages as needed. By making it easy to call new Julia code from an application running Julia 1, you’d be making twice as much work for package maintainers since they’d end up needing to support two entirely different runtimes for an extended period of time (since there’s no reason for users to upgrade, so they won’t). Not to mention much more work for Julia devs who have to support not one but two bidirectional runtime systems. I can tell you that even just making Compat.jl work during the 0.x days was not fun.