Currently, a single Ruby toolchain build is a collection of separate Ruby versions identified by a single commit hash.

There are a few drawbacks to this:

1. Duplication. When we need to add a Ruby version to the toolchain (or remove one from the toolchain), we have to rebuild all the other Ruby builds, even if their corresponding builds in the previous toolchain version are still just fine
2. Obfuscation. The toolchain builds are identified by a commit hash, which does not communicate anything meaningful (by itself) about the contents of the build.
3. Complexity. When changing the build matrix to use a different host OS, or a different Ruby version, it becomes necessary to look back at the recipe for the toolchain to see if the needed Ruby version has already been built for the given host OS. If not, the entire toolchain must be rebuilt and updated (see Duplication, above).

I propose that we rethink our toolchain build process:

1. Rather than artificially grouping Ruby builds under a toolchain commit hash, let's simplify and just tag each Ruby build with the Ruby version and host OS.
2. Then, we adjust our test scripts so that they no longer care about a "TOOLCHAIN_VERSION" at all. The scripts already know the requested Ruby version, and the current host OS, so they should be able to just reach out and grab the specific build they need.
3. The new toolchain build process will always rebuild all specified Ruby version/host OS combinations, but overwrite them in the cloud if they already exist. (This makes it easier to correct a broken Ruby build.)

This shouldn't take too long to implement; our toolchain build process already tags ruby builds by version and host OS, so all that is needed is to fix the uploader so it no longer associates them with a commit hash. On the product side, the test scripts would need to be updated similarly, omitting the commit hash and instead looking only for the given ruby version and host OS. I suspect it could be done in less than a week for the driver, with other products adapting more quickly once the foundational work is done.