We do not need to future-proof languages, we need to make them replaceable and able to interact with each other.
I believe the biggest problem to be environment/io access. It will be the bottleneck of most new language implementations and encourage people to update the old instead of creating the new. A simple fix would be to separate both, like in this blog post having input/output instructions and leave the actual environment interaction to something else.
Start by changing society to not chase new-ness over stability. Alas, as long as promotion to principal developer and beyond (with the associated hundreds of thousands of USD in compensation increases) depends on doing daring new projects rather than keeping an old project alive, I don't see the trend changing anytime soon.
> Alas, as long as promotion to principal developer and beyond
This is a problem that we can actually blame on techology rather than programmer psychology. Yes, software changes for many reasons (including the reason you give), but the fundamental reason why software keeps changing is because hardware keeps changing. Any software that refuses to change in order to take advantage of new hardware is replaced by new software that does. You will never, ever get software to stop changing until hardware is frozen in stone... forever.
Probably the best example of a programming language for society would be psychohistory from the Asimov novels, but its spec is vague at best and I know of no working implementations.
Fear not! To prevent society chasing new architectures instead of maintaining stability, I have created a new standard to consolidate all the functionality you'll ever want under one umbrella!!
As hardware asympotically approaches a stable state (flattening of the Moore curve), languages will follow, I'd guess. Assuming quantum computing doesn't take off, this would mean that languages wouldn't have to radically change to adapt to new technological capabilities (e.g. parallelism). Betting on the future is always a risky game, however. It might be smarter to have adaptability built-in to the system (rather like how RISC-V has been set up, with a stable core plus modularity, extensions, etc.).
But I think we are still far from approaching the stable post-Moore state. Being post-Moore is forcing engineers into exploring wackier and wackier architectures to squeeze out what computing power they can within the physical limits. Post-Moore life demands that we use parallelism anywhere and everywhere we can. A high degree of parallelism often requires a large memory set. Put those things together, and you're intensely battling data movement latency and cache consistency and contention issues. A solution that has recently emerged: rather than have each (hardware) thread tied to a core that has to manage the movement and consistency of data from RAM into nearby caches and back, instead have the threads migrate to the data. [0] Naturally, a lot of work is needed on the compiler side of language design to support this well without burdening the programmer. I don't foresee these kinds of new hardware ideas stabilizing any time soon.
I believe the biggest problem to be environment/io access. It will be the bottleneck of most new language implementations and encourage people to update the old instead of creating the new. A simple fix would be to separate both, like in this blog post having input/output instructions and leave the actual environment interaction to something else.