Apple introduced their ColorSync technology a couple of decades ago. (Early in my career I worked on the ColorSync team.)

Apple relied on ICC profiles (International Color Consortium?) to define the color characteristics of each device in a color workflow. You would not modify the bytes of the image source as it passed through your pipeline, merely rendered it differently using the ICC profiles and math.

A computer display generally has a much wider, richer color gamut than an inkjet printer. Naturally an image rich in color can look better on the display than when printed.

When going from a wide gamut of the source image to a much smaller gamut you have some choices as to whether you want to simply clip the outlying colors and therefore "mute" your dynamic color range or whether you want to scale down the entire gamut of the source image to try to fit it within your destination gamut; or some other compromise (called "rendering intent" in the ColorSync jargon).

There were other issues like color temperature and issues specific to specific devices: white-point, black-point, etc.

A nice thing about this workflow was of course that the source image was unmodified across the pipeline, rendered as best it could be for the specific output (with the specified intent). The math worked well enough in fact that you could map the source image to your printer profile, and then map those new values to your display and essentially "proof" the image: see what the image is likely to look like when the gamut is restricted by the print device.

When Apple and other companies started introducing wide-gamut displays this was a very exciting development since it kicked open the gamut of our displays and a properly color-managed OS could, for example, really show you some of the rich reds the cameras had captured (in RAW of course) that previous display technologies could not.

Funnily, a non-managed color workflow on the same display would look "off" as things like the red close buttons in the window corners looked blazingly red, painfully red almost. Specifying RGB as (1.0, 0.0, 0.0) for red was no longer going to look right, now needed to be pulled in to a gamut we were more used to using something like (0.9, 0.0, 0.0). (Software of course would naively still specify (1.0, 0.0, 0.0) but I believe when the window backing store then rendered those pixels to the display it did the color matching that pulled the red down — if you wanted to display a RAW image you would assign that camera's ICC profile to the backing store to prevent the default match.)

The downside of the ColorSync model was of course every device had to be calibrated. Displays were fairly trivial but printers, as you probably know, needed a different profile for not only different inks but also different papers as the same magenta ink will look different on coated versus non-coated paper. And printers were particularly bad color devices because there were no good mathematical models using power-curves and black-body temperatures the way a display could be modeled, instead large 3D tables of color values, printed and carefully measured and later interpolated between were needed for each ink + paper combination.

sRGB was something I remember Microsoft getting behind. The model was, I was explained, to define the color space that 8-but RGB values were supposed to conform to. So if you could dial in your display to display sRGB, your printer to print sRGB, then no color management is really needed — WYSIWYG.

The downside of course was that sRGB was a narrow gamut that gimped displays capabilities and yet I suspect was outside the capability of many printers.

Adobe only slightly remediated that by creating AdobeRGB that followed the same idea, just kicked open the gamut a bit more.

Anyway, that's the way I remember/understood it.