This is not really an Operating System Command at all, though. It is an Application Program Command (U+009F).
APC is far less supported overall by terminals (for example, Terminal.app on macOS would simply dump APC to the screen, ignore the framing, and treat the APC data as normal pty data, and Terminal.app is used by a LOT of people). Plus, its anything-goes format makes it hard to ship safe protocols that overlap with others (APC was always meant afaik for _one_ protocol -- the application's, not multiplexing many).
Compare this to OSC which is well supported, has a well defined multiplexing format (the first number), and has a well defined framing that all terminals I know of ignore for unknown values. That's perfect.
As the Arcan project so eloquently stated[1]: "Terminal emulators emulate a machine that has never existed, a fantasy computer." More details in the link by people I respect who have worked on this problem far longer than I have.
[1]: https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-e...
In fact, you can say the exact same thing about OSC (it was meant for one protocol, the operating system's) as you just did about APC. Because that's what ECMA-48 actually says: 'The interpretation of the command string depends on the relevant operating system.'
There is no operating system standard for this in the Unices or in Linux-based operating systems. As I said, this is something that haphazardly grew in the last decade or so as people decided that they needed some kind of terminal control string, and how dtterm and xterm had been processing OSC (very limited compared to all of the things that people have nowadays tacked on) was there.