in all of those cases, we tried to provide a simple method for users who depended on the legacy behavior to restore it with a simple configure change which was advertised in the upgrade instructions.
This is precisely what I suggested doing.
In every one of those situations (that i can remember) we still had a few users who got confused/frustrated at the change in behavior.
The change I'm proposing doesn't change behavior. It changes configuration. The two are different.
I'm not suggesting that we should always strive for 100% back compat in the configs and the request params and that people should expect identical configs to always work in every Solr release for hte next 74 years - but so far, the only times we've (knowingly) broken existing configs it was when the goal was to either improve the default behavior, or add additional functionality. I've got no problem telling 40% of our existing users "you need to add foo=bar to your config to have it keep working" if it means that the other 60% and every other new users gets something good out of deal....
"good" is a qualitative term. I consider strong system design and organization something that SOLR should be good at. All of the other qualities or observable aspects of the system (performance, efficiency, scalability, etc.) are also important things – however, not to this issue.
....but i see no good reason to break things for a large percentage of our user base when there is no value add to them in return ... having a (subjectively) cleaner code base is not a justification for making an upgrade break unless users edit their configs, or run a script.
There is value added in better system structure, architecture and code organization. There are plenty of books written about the benefits of this and I won't bother to go into detail. Further, "upgrade break" is sort of a loaded phrase. It's not a break. It's an upgrade. Break would imply something out of the norm, and I don't see any formal SOLR upgrade process that the approach proposed in this issue deviates from. You suggested yourself that the types of "upgrade" notations that this issue proposes in are advertised in CHANGES.txt. This issue is no different.
If breaking things was the only way to fix some major bug, or add some cool feature, or saved us 100 man hours of development then i would be completley on board telling people "sorry, please change this one line."
There are many phases to the software engineering lifecycle. Development is just one of them. This issue addresses time/cost savings in understandability of SOLR's code base. For the quantitative value, I'll omit guessing as to the general savings and just point to you to some reading on what bad code organization and system structure can cause in terms of cost when others try and understand your code   .
but when keeping things working takes such little effort, it would be completley irresponsible to ___ our users over like that - trivial ___ like needing to make a nusance edit to a config file for no apparent reason is what drives users away and leaves a bad enough taste in their mouth that they actively trash talk a product/project as being "unstable"
I'm both a software developer and a user of SOLR, and the consistent resistance to any proposed refactoring is quite troubling. As Uri noted above, software requires refactoring, SOLR is no different. And as I noted from a code organization standpoint, placing classes named response in a package named request is not subjectively anything – it's poor design and it needs to be addressed. As for "no apparent reason" as I mentioned to Noble, end-users of a system don't dictate its code-level organization/design.
I'm also of the opinion that there are many stakeholders of any distributed software system, SOLR being no different. Patrick iterated them above, as did I and as did Uri. There aren't just "users" of SOLR – there are end-users, system administrators, core developers, plugin writers, architects, managers, etc.