It is indeed a failed design. What you describe is how FV2 in Apple devices work. You have a native always-on DEK (Data Encryption Key) in the SEP (Secure Enclave Processor) that itself is encrypted with a KEK (Key Encryption Key) which in turn can have multiple encrypted versions for different end-users, which each has their password to decrypt the KEK, or better, authenticate to the SEP and it will decrypt the KEK. This is not exactly how it works, but a simplified story.

On top of that, there is indeed a small secure pre-boot stage where the user (any local user) logs in, which does both the OS login as well as the disk decryption (well, KEK decryption but that's a detail). It is of course also using a KDF so it's not just the end-user's password plainly applied to a cryptography function. This too is a simplified story (the pre-boot isn't actually a preboot, the OS is on a read-only signed volume since it's not secret/confidential, it's only important to prevent tampering).

This works, it works well, and has not had any real durable attacks that work against it so far.