Hmm... well, old patches should run OK if the lib is explicitly loaded.
But it's a bother that new patches that pull zexy in explicitly won't
be able to use pack~ and unpack~.
That's not really true. What happens when zexy or any other external is called with the same name as an internal object is that Pd renames is and creates an alias for the old one. This used to be printed in the console at level '2 normal' but now needs a higher level (and I don't know why, seems like an important normal message).
In fact, zexy already aliases and replacs [abs~], which is ok because it offers the exact same functionality, but you can still creat pd vanilla's as [abs~_aliased], same would be true for [pack~_aliased] and [unpack~_aliased], but yeah, that would be a pain.
The best solution I can think of is
to either find a different (unused) name for the new pack~/unpack~ or
to offer a new name to zexy's versions (and keep the old ones too, perhaps
in a separate "library").
There were issues in Cyclone as well and we found a way to keep the name and not clash. We force and allow using things like [cyclone/line~] (called from a single binary) without clashing with vanilla's [line~] - we allow something like [cyclone/>~] (loaded from a library) which prevents clashing with zexy's [>~]. Maybe zexy could do something like this, but old patches that use zexy's pack~ would not work in new Pd Vanilla versions as they'd call the new vanilla objects instead. In this case, maybe a warning when loading a new version of zexy that pack~/unpack~ needs the 'zexy' prefix solves it.
For reference; Cyclone objects that don't clash with vanilla objects: append, pow~, line~, clip, clip~, table and snapshot~
cheers