I try and keep backups of all of the tools used to produce any project. This means, for example, keeping the exact version of MPLAB used on that project, despite the fact that newer versions *may* still be compatible. I preserve my old Microsoft compilers and Borland compilers and Zortech and Lattice C and so on, for exactly the same reasons. I have so many of these around now, but I keep them maintained together with the projects so that I can always go back and reconstruct the executables. So your last sentence about retaining tools for future product support is right on target. That is a must.
The above issue comes to the fore for me when developing on a tool where I may not be able to legally restore the compiler toolset. In those cases, I try and avoid the tools in the first place. An example here happened in the case of tools from Analog Devices, where the toolset was key-locked to the machine. What happens to me, say 5 or 8 years later when a client asks me to make a small but important feature addition? I set about to recover my tools and source code and, no longer having that exact machine with the exact same disk drive, discover that I cannot operate the compiler, at all. So I call up Analog Devices for help. And do you imagine that even they know how to help me, after so much time has gone by? Or will keep records of my ownership that long? Or still have their own tools by which to regenerate the unlocking code given information I provide them on my new system??
I stay away from such situations like the plague. This is one of the reasons I do NOT use tools locked to machines. I am still, today, supporting tools where the code was developed using Lattice C around the year 1987. I still have the complete tool chain used for that project, including some tools by Intel needed for the locating part of the linking process. And because the OBJ files of Lattice C aren't entirely compatible with those locating linkers from Intel at the time, I also have a custom tool needed to modify the OBJ file so that it is acceptable. I have that tool and the source code and the development chain for that, too. The point here is that I need to be able to support clients I have for periods of 20 years and longer. So my concerns about what tools I buy are severe. (Similarly, I have working 80286 and 80386 machines I keep around, along with boxes of multi-I/O cards, floppy and hard disk cards, and so on to maintain them -- when I find some tools will not run properly on modern PCs.) So I will only use tools I can rely upon, even when the vendor has gone out of business entirely and cannot be called upon. This means no machine-lock crap, unless the vendor is willing to give me an unlock code that will work on any machine. (An owner of Paradigm, after listening to my needs, very generously gave me a complete toolset with such a code, for example.)
Regarding 'bugs' or whatnot, I just gave an example above where I
*had* to develop a tool. The Lattice C compiler did not, at that time, have the ability to locate code. However, the system is not PC compatible and is a dedicated 8088 design -- a truly embedded system. So I had to use the Intel toolset for the locating feature. But to make that work, I needed to build something to mediate between the OBJ files that Lattice C wrote out and the OBJ files that the Intel tool could accept. Sometimes, this happens. And when it does, you do what you have to.But then, it's easy to explain to people why you did. There is no real question.
Jon