For a single-user system, the approach you describe is probably fine, but, IMO, for multi-user systems the patch should be sent first to the maintainers, and have the fixed version come back as a standard distribution.
You're full of it. You can make changes to system libraries before and independantly of the vendor if you document it and make a plan for dealing with this disparity between your system and the rest of the world. You can do what I recommended which was to get that change into the official version or you can maintain your forked version. Either way, it isn't forbidden. It's not a good idea and it's a last resort kind of thing. Doesn't mean it isn't occasionally necessary.
I see that you want to get approval for the idea that it's never ok to change a system library like this guy did. Sure. That's fine. He broke production and didn't bother to test, notify the other users, or get their approval. That deeply, deeply sucks. It doesn't mean it should be impossible for him to write patches. Assuming the guy grows a brain next week and learns how to write valid code and it comes to pass that a core library has a bug, it really might make sense for the thing to be patched.