I am a little confused here. One of the design points for the MI is the ability to add information to the commands without requiring a change in the clients (unless, of course, they wanted to use the new information). That should mean that we have set up a situation where we can change the mi in substantial ways without having to demand that clients rewrite their code to use MI. Shouldn't that mean that we can go a long way without having to make incompatible changes? And so, imposing the burden on ourselves of not jerking clients around all the time would not be such a big deal, and perhaps worth the inconvenience it would cause the MI developers?
Yes, that's the theory. There are always problems though:As a client of the MI, this means that in a year or so I have to expect to rewrite code that works just fine, because you have deleted the support for it from gdb; or carry the burden of maintaining mi1 as patches to the gdb sources. And longer term, I can expect to do this again next year, unless things "stabilize" before then, which they may or may not do. This doesn't sound appetizing to me.
The MI is a public interface to gdb - and the only really useful one we offer to external clients who are not Human beings right now. It has been around in gdb, and we have been using it contentedly, for a couple of years now. A retroactively stated policy of instability in this interface (including the vanishing of useful variants at odd intervals) seems very unfair to those who have been using it right along, as well as being one which can only slow its uptake in general.
What we're seeing here is the fallout that results from a number of
players creating localized GDBs. GDB developers have started looking at
the underlying problems that Apple and others encountered, and are
trying to fix them. Regretably, per above, this is going to need some
short term change.