Thanks for filing! This is indeed a bug, but it's a tricky architectural issue for now.
The root cause is that using the "Add New Rule" action (button or context menu) will immediately invoke the injection of a new CSS rule with the auto-generated selector matching the element. When changing the selector and committing the value, the previously injected rule is updated, hence why the removed old selector shows up as removed when the expectation is for just the new selector to show as added.
Basically, adding a new rule is a two-step process which get aggregated in the Changes panel as an added, then edited CSS rule.
The solution in the current Rule view is to create a mock Rule model, push it to the ElementStyle list of matched rules (though it doesn't exist yet), use it to update the Rule view UI, then send it to the PageStyle actor only once the selector input field is committed.
The existing architecture for the Rules view makes this tricky. The mock Rule model needs a real RuleEditor instance, forced updates and recalculations of the ElementStyle rules, and the concert of events fired which re-render the UI needs alterations.
This will be substantially easier with the new Rules view currently being worked on in bug 1518615. I'll mark this bug as a P3 to put it as a reminder on the backlog for now. We'll attempt to fix this in the new Rules view. Fixing this in the old (current) Rules view involves added complexity that's destined to be short-lived.