I'm thinking in terms of, where do we draw the bug fix/new feature line on release branches. "Enabling nested lists" doesn't change any existing behavior, but we also need to ensure that the code change does "enabling nested lists" and nothing else, and that the way it does "enabling nested lists" doesn't break anything. Of course any bug fix has the same problem, but there's a spectrum from "the table name is misspelled in the Oracle query" which is a pretty darned safe fix, to something more subtle like, "this API call is confusing to invoke." This change is in the middle of the spectrum - not because the desired change is likely to be backwards-incompatible, but because it's a change to the code behind some widely used functionality.
So if we are going to change riskier stuff on a release branch, I think we should mitigate the risk via both code review and regression testing, whenever possible. We should do this for the hairier code bugs as well as for the design bugs.
