For a long time, I’ve believed that the actual solution is to make the system transparent enough that a compromised system is obvious. Imagine playing hide and go seek in the salt flats

I agree, however the fundamental problem here is that transparent systems are on the far side of the axis from user focused systems, think about it, the whole point of building a user interface is to hide and remove choice from the user, to change the system from "A steady hand with a magnetic needle" to "point and grunt" the whole point is to build a shiny facade that hides the inner working of the machine. So while you and I and many other people like to see the machine, the inner workings whirling around in grandiose majesty. Millions of man hours have been spent hiding that stuff away keeping it from view, pretending it does not exist. And thus the transparency of our computing environments have suffered correspondingly to this focus on hiding things.

That seems ≈impossible in a world where you're running arbitrary, Turing-complete code. A modern consumer machine can do so many different things—often a bunch at a time—that there is always a massive amount of space to hide bad behavior.

There might be some way to design a system from the ground up to avoid this problem (some kind of declarative, capability-based security?), but retrofitting that onto an existing behemoth of a system does not really work.

If I log into my system it's safe. If someone reads my password off my screen post-it and logs into my system it's quite thoroughly compromised. How would you demonstrate which of the two sessions are compromised, during the act?

What does that actually mean?