The transfer functions (commonly and mistakenly, referred to as gamma ramps) used in the various color spaces are related not to the displays but to human visual perception. They are designed to give a perceptually uniform response given the expected viewing conditions. That is, each change in input signal gives a uniform change in brightness perceived by a human observer. This means the entire bandwidth is used for information useful to the human eye. Encoding to one of these transfer functions is a form of lossy compression.
sRGB’s transfer function was designed for the expected viewing conditions of a computer monitor. BT709’s is designed for the average living room. Those used in digital cinema are designed for the darkened viewing environment of a cinema. Since they are related to human vision, these transfer functions remain valid despite improvements in displays.
The fact that the response of a CRT’s electron gun is almost the inverse of the human visual response, therefore making the CRT a perfect decoder for the desired signal compression was a happy accident for (or as Charles Poynton calls it “God’s gift to”) television engineers. If it hadn’t been that way, they would have had to invent something that was.This usefulness, as well as the legacy content, is why displays continue to have transfer functions.
I think having to adjust parameters for each application would be a pain. Adjusting them for the display systemwide is the right approach. Of course not all systems provide such controls.
If the alternatives are useful, I would not object to having them. What you are proposing is something in addition to linear and sRGB back-buffers. Let’s call it custom. How would browsers deal with it? I noted some of the difficulties in my introduction.
BTW, I hope current browsers are converting the current linear back-buffers to their compositing color space. I wonder because such conversion has considerable overhead.