You don't challenge them by pretending they don't exist. That only make you look like an asshole.
The proper way here would have been two pull requests, one with all the bugfixes, and one with the new feature with a cover letter motivating why an exception should happen. And if this happens often enough with sufficiently good backing motivations, then he may be able to convince people.
I have had a similar experience with a team member who was quietly unhappy about a rule. Instead of raising a discussion about the rule (like the rest of the team members did) he tried to quietly ignore it in his work, usually via requesting reviews from less stringent reviewers.
As a result, after a while I started documenting every single instance of his sneaky rule-breakage, sending every instance straight to his manager, and the person was out pretty soon.
Linux caught Kent when he tried to sneak in non-bugfixes into a RC, and berated him.
After that (not before, this is a critical distinction) Kent said "I don't want to abide by the rules, because I have my concerns".
This is very similar to the situation I have described, except that in Linux it was Linus who was skipping reviews on Kent's code trusting him not to subvert the rules, and in situation I described the team collectively was trusting each other not to subvert the rules.
You've explained everyone is unhappy with it and that you worked to get the one person who actually acted upon it fired. It's hilarious but in a pretty sad way that you're portraying this as an inevitability. It wasn't, it was just you. You had a choice, and you chose to do this. It wasn't inevitable.
I didn't make myself quite clear — the others were raising points on _other_ rules, and as a result we tuned the rules quite often, as we discovered what works better and what works worse.
So it's not ok to challenge things like the substance of rules...