D'oh... I get so stressed when I have to install and configure a new OS! I feel I'm not finishing ever!
This is the issue with the plugin override. Of course, they're more dangerous than events as they are operating directly with data that the core uses for its own. This is different from the case of events in which data is sent to plugins and they can do whatever they want with that data. So there is a risk when using even a silly override: suppose you want to override a function that returns an array with valid values and you want to allow an extra valid value to the array. So you just call the parent function (the one you're overriding), then add the element in your overriden function and then return the array. This will work flawlessly... but what if the core, in a minor update, modifies the returned value so that it can also return a null value? Then that could break your code or worse: adding an element to a null $arr variable in this way $arr['new'] = 'val' would create the array and assign that element... so you'd be changing the data the core uses to make decisions and hence, the core's logic.
So there is a risk in a simple plugin override that calls a parent method and adds a single element to an array. Now, the override of this plugin is not calling the parent which, in practice, is even worse. This is because, in case of an update, the core's function could change. And not only change the result value but any part of it, for example, an event could be generated, an email could be sent, and IF statement could be added to split the logic of the function, etc. So any change that the core performs to that function won't be executed because the plugin override is replacing the whole function instead of first calling the core's version and then performing the plugin's custom logic. So when you replace a whole function there is more risk when upgrading.
In both cases, but particularly on the second one, it is important to keep track of the changes the core performs to that function so that a developer can compare the override with the new core's function. If they are have not change, it is very likely that the plugin override would still work. If they have changed then the override, in the first scenario, should be checked to see if it needs changes or not. In the second scenario, in which the function is fully replaced, the function must be changed.
I went ahead with this and took an actual look at the function, then performed a diff with the current 1.7-beta-2 versions. Luckily, the diff only displayed one line with the !$rules['queued'] removed. It is possible to go for the first scenario in which you call the parent in this case. Just call the parent in the override, then get the $rules array, focus only on the $rules['editbutton'] and modify it in a similar way as you did in the current override and then just return the $rules array again. That is much safer as, if a new rule is added in 1.7.1 this solution won't break while the one currently implemented would as the rule would be omitted.
Having said that, IMO, the most important issue here, is that the plugin is changing the core's logic. Other parts of the core might depend on that rule or make assumptions based on it and now it is different from what the core expects. That might bring trouble to the core itself and to plugins that also depend or make assumptions on data that is derived from that function.
Anyway, due to the nature of the requirement, I don't think this could be solved in a core-safe and user-friendly way (e.g.: using events) :/
