Seems like a good idea -- I've seen issues from time to time where something got accidentally unprotected instead of downgraded from one protection level to another (especially if you just let the higher-level setting expire naturally).
Multiple interacting settings can be a bit confusing though, so it probably needs more attention to the user interface design -- that whole form needs a redo to begin with. :)
I'd like to also see some thought on the interface. But it should also be possible to make the backend changes without touching the existing UI much.
Definitely; the current UI interface is pretty cruddy. If we're now referencing protections as unique object, there should probably be some refactoring on the backend into a Protection class (or maybe "Restriction"??), and then frontend interfaces rather similar to Special:BlockList (for listing protections of a given type or as applied to a particular page) and Special:Unblock (for removing protections, although this would be nicer as a checkbox list of protections-to-remove, as suggested).
Agreed that the UI may need to be overhauled rather than merely added to in the long term.
I've implemented the proposal without recourse to a Protection/Restriction class, but it's certainly possible.
So in other words, I agree :) But do any of these suggestions block work, or is it better to make the change and then refactor? (That's an honest question: I've never worked on designing proper software before, so I don't know which turns out better in reality.)
[Addendum: Also Brion's suggestion of reforming protection logging, although presumably that would move logging into page_restrictions/protected_titles, which is a fairly major operation by my reckoning.]
