For this inconvenience, the gods of operation systems invented a few things to lighten your burden:
- directories, which have names, and can hold vast amounts of files, with names, and subdirectories with names, which could for example include a version number or name
- a PATH variable, that could point to the executables in such a directory, inconveniently that one is usually called .../bin instead of .../exe - but well, one can adapt, right?
- a LD_LIBRARY_PATH variable, or similar, if PATH is not good enough to load helpers/DLLs and such
- shell scripts, that can set PATH etc. or alias commands if you want to switch quickly
- local .my_tool directories and a help script/command to launch your problematic environment, based on what is configured there ... that is for example what Ruby does
Sorry, there is one thing: you want to run your old Python 2.x Python scrip under 3.y? Well, then you have to port it. Just like I have to port my 1989 K&R C program to my 2025 C++ compiler.
If you have other problems with "old" Versions of "tool X", and are not able to fix installation directories, sym links, PATH and/or LD_LIBRARY_PATH and have a helper script, then fooling around with computers is your wrong hobby.
Try gardening. Or watch stars at night ... something like that.