Truth be told, other package managers have these same variables to. They just simply bake the assumptions made about those variables into the rote techniques they employ to implement the system. Sobyks primary sin is that it's intended to be use for multiple systems for packaging at once.
But there is a great utility into locking down the loose ends that are not really loose to begin with. If someone knows what platform they want to target, that is not a variable anymore. If they know what version of Tcl, again, it's not a variable. If someone is targeting to interact with a population of packages, you can just assume they need to conform to whatever set of assumptions allows all of those packages to work at once.
What you find is that there are solutions sets for many of the variables that describe large populations of users. In physics they call that a Frame of Reference. I'll just shorten that to "Frame." A frame is nothing more than a bundle of assumptions. Two parties in the same frame can ignore a tremendous amount of really exotic physics interactions. Two parties in the same Yggdrasil frame can flatten a multidimensional monster into a filing system.
What is an Yggdrasil, do you ask?
It's like a tree structure that you are familiar with from basic CS 101. However, instead
of having an absolute root, the "center" or "base" of the tree is whatever point you
are standing on. Following links out makes the structure more and more complex. And many
paths can lead you back to where you started from. I take the name from the Norse concept
of the World Tree. Legend has it that the tree is so immense that the leaves of the tree
are knotted up in the roots of the tree. It's hard to envision, but some artists visualize
it thus:
How does one maintain this frame? Well fortunately we are implementing Sobyk with a user front end. My thinking is that throughout the process, that front end maintains the frame based on user preferences, and even allows them to customize that frame or even swap between several frames at once. Your package selection will be driven by the frame you seek. And thus, if a developer really needs to keep alive an application written 25 years ago that is built on a really old Tcl (say 8.5), and all other things being equal, he or she can still pull updates from packages that don't otherwise require a Tcl greater than 8.5.
At the same time, we can even track how many users are using a given frame, and use that as a way of gauging where to invest time in testing, bug fixes, and other QA issues.
Simply knowing a platform and a Tcl version is not enough, there are a host of design decisions that go into a frame. Even getting all of those variable documented will be a great big help. Having user's clients report to use the frame they were using when they had a problem will do a great deal to help replicate issues for testing. While at the same time, keeping the fact there is a frame hidden except when absolutely needed will keep searches from turning into an absolute nightmare for users.