Level 4 MQ's adds:
scripting: Apply styles based on the presence/ absence of JS. If you haven't built it to work with and without JS then a MQ won't save you. A more common problem is scripts that fail.
light-level: Three levels which aren't quantified. Devices often adapt anyway, different screen technologies wash at different levels, sensors are inaccurately calibrated. If you're not using it very carefully you could do more good than hard - how do you test reliably? Maybe use it as an informational trigger.
pointer: Presence and accuracy of a pointing device. What about multiple inputs? Browser now has to understand the meaning of "primary". It's a boolean that has lots of uncertainty. Switching between them in real time could drive users mad. Apply non-destructive progressive enhancements as the context becomes clearer.
hover: Can the browser detect hover? Should reflect the "primary" input method. Don't rely on this, use progressive enhancement.
update-frequency: How fast the content can be updated - paper, e-ink, high quality screen.
overflow-inline: What happens when content overflows the viewport. E.g. scroll or paginate.
Combining all these on different devices can get to a difficult matrix and might not give much basis.
With Android you can place assets in buckets using qualifiers and at runtime it will select the right bucket to draw the information from. You can change the layout (and others) based on tons of factors.
What if we could trigger a native component (like a menu). We have a component that works right for the device - like form components. Adaptable and platform appropriate.
In Android you can declare a component and the data and the device will render it in the most appropriate way.
Web components have the potential to do this. Developing new tech ist the easy part, understanding what we need and what for is much harder.