"not breaking existing code" and "fair warning before removal" are the important aspects of such changes, of course.
Thanks for the well thought note. I think we're fairly well on the same page (you and I, don't know about the rest).
I said it's an evolutionary process and that we should restrain ourselves from renaming just for renaming's sake (I wasn't implying that the new parameter namespace fell into this category, I know you added functionality etc).
You're saying there are a lot of things in the utilities space that could clean-up work, refactoring, and outright bug fixing and that while doing so using namespaces to better organize the code would be a good idea.
I don't see any large-scale disagreement in those two paragraphs.
Especially since when doing such cleanups and refactoring we want to encourage getting it right even if the calls change. This frequently implies adding a new proc (so you don't break the old) and there's no reason to maintain the old name style for the new proc.
One think that's needed is a well-documented way to deal with deprecated procs and their disappearance. Removing them one or two releases in the future after ample documentation that they've been deprecated and after explaining why. That sort of thing.
