i think, that the question, why a new object [pack] is named pack is not rhetoric at all and isn't answered yet. so lets go again: why is [pack] from zexy called [pack]?
because it is meant as a fully backwards-compatible replacement of [pack], with added features. since i have been repeating this for several times now, i would be interested in the precise part of the above sentence that is unclear to you.
Perhaps there is a conceptual difference between overriding internal classes for a class with the same behavior but with added methods (e.g. the [print] and [soundfiler] examples from before), and overriding with a different object, or one with a different interface (the [pow~] situation).
For instance I think it would be at least a well-motivated task to write over [tabread4~] with one that inherited everything vanilla [tabread4~] could do, did those by default, but added methods for Hermite interpolation instead of Lagrange. Meanwhile, it would not be well-motivated to override it with an object which (to be silly) indexed tables in reverse, or (to be ridiculous because it's 4:00 AM here) grabbed a random joke from the web every 64 samples and posted it to the console.
What's unclear -- and to me probably the most important to solve as a result of this thread -- is what to do when vanilla adds features which potentially clash with objects in existing libraries. After all, this would be a much shorter thread if the problem were in a new [rfft~] object from some library that output bins in the order they appear in SuperCollider, thus breaking vanilla [rfft~] patches every time that library was loaded -- "in the name of gbuzz stop what you're doing and fix the library!"