This is already the case. If choosing full disk encryption in the installer, luks will be used. There’s no backdoor. We cannot help with recovery. Nobody can at time of writing except if using weak passwords.
I don’t like this feature. Could also be considered an anti-feature as it prevents raw disk backups, data recovery and makes malware analysis almost impossible.
Can be a separate feature request. If popular, might become opt-in. Faster if contributed.
Unlikely.
Firmware feature. Can be user controlled by a secure, non-resettable BIOS password. This is something I am interested in and it might be realistic.
Can be a separate feature request.
(Why realistic? See verified boot forum discussion.)
User controlled, Sovereign Boot: Yes.
Can be a separate feature request.
Vendor specific lock and no unlock available for device owner: No, not planned. No support for the War on General Purpose Computing as per project values.
The ability for the device owner to physically unmount the root disk, the ability to decrypt their own data if they know their encryption password and the ability to perform malware analysis is a crucial security feature.
An obfuscated blackbox that cannot be scrutinized is the opposite of values and goals such as Open Source, Freedom Software, reproducible builds, bootstrappable builds.