Maybe the collective brain power of the forum community can come together to think of a way to solve the problems that currently require Cantabile to limit you to one instance of a rack at once. One of the problems (if I remember correctly) is that suppose song A has two instances of a rack, and song B has an instance of that rack. Which one of the two instances from song A will be used in song B? It's important because you may wish to play sounds continuously on that from song A into song B. But how does Cantabile know that's your intent? What if both songs have two instances, where you may intend to maintain continuity across songs for both? How would Cantabile know which ones to pair up?
How do you deal with situations in a single song with two instances of a rack, where you modify one instance? Does it change the other instance automatically/immediately? Are they clones in all respects apart from currently selected rack state? How do you decide what things should change in the other instance, and what things shouldn't? What happens when you save the song - do changes to both instances get stored in the single rack file? What if there are conflicts, where different changes have been made to the same thing in both instances?
Should it simply be an "internal" version of the use of symbolic links? In which case multiple instances of racks will overwrite the common rack file when they're saved, and the other instances will remain as they are until they next happen to be loaded, at which point they'll bring in the new version of the rack. Is this desirable? Dangerous in some cases?
Should Cantabile allow you to load one instance "normally", and then additional instances in a kind of read-only mode, where you can't change the rack once its loaded (apart from rack state), and only the "normal" rack instances can be used for continuity between songs?
In many ways, embedded racks are an answer - you can load a linked rack and convert it to an embedded rack multiple times in a song, thereby having multiple instances. But you lose the ability to make changes to the embedded racks and have those changes appear in the linked rack file - it's a lone wolf, no longer associated with the original rack. Also you lose some of the memory-saving advantages of linked racks.
I don't think these are all just technical details for Brad to work out - they affect how we would use multiple instances, and what some of the dangers would be. So perhaps it's down to us to come up with some carefully thought-out ideas about how it could work in our various different scenarios.