I can't help but twitch a little at this observation. As an engineer who's sat on calls with Image Video programmers to set up our super complex tally system, we only tally for things that are in P/P (primary bus) preview (green or yellow) and P/P (program). If an M/E (mix bus) winds up in P/P, it gets tallied and only then any associated sources in that M/E also inherit that tally status. That is a fairly accepted practice in broadcast control rooms. That's not to say you couldn't implement that in such a system, but it's also the price of a condo, and I'm sure there's someone out there that's caved and implemented it (and then perhaps regretted it later).

But I digress.

The vMix TCP API tally subscription functions a lot more like the inherited tally scenario described above. That would cover the latter of your scenarios. Guidogast's wireless tally light project uses the tally subscription, so those tally lights will also behave in the same manner.

The discrete mix bus tally scenario is a bit more specialized, but not entirely unaccounted for. There are InputMix and InputPreviewMix activators. Adapt a project like this one that uses a Teensy board and you can have external tally lights for those.

Want to combine the two scenarios? You're best off using the first project and adapting it, but that will involve lots of coding.

Obviously these are external solutions, but they are your best shot with the existing system.

I think offering feature requests that add functionality rather than fundamentally changing it and potentially wrecking it for everyone else tends to be more constructive. In this case, I think expanding the TCP API so that you subscribe to specific busses separately while still having the option to subscribe to the traditional tally logic is a happy medium. It would also make the wireless tally light code easier to adapt to your needs.

I'm not going to beat that drum on other's behalves, but feel free to take it and run with it.