Question about FAQ 5.21: "Why is there no "Nuke-Option"?"

After seeing GrapheneOS's implementation of the same design idea, I feel
like this idea wasn't given much thought in the FAQ.

> While this sounds attractive at first glance, it does not make sense
> once a real security analysis is done.  One problem is that you have to
> have some kind of HSM (Hardware Security Module) in order to implement
> it securely.  In the movies, a HSM starts to smoke and melt once the
> Nuke-Option has been activated.  In actual reality, it just wipes some
> battery-backed RAM cells.  A proper HSM costs something like
> 20'000...100'000 EUR/USD and there a Nuke-Option may make some sense.
> BTW, a chipcard or a TPM is not a HSM, although some vendors are
> promoting that myth.

This paragraph ignores the fact that the TPMs that come with computers
have improved on-par to the standard of HSMs, and are now integrated
straight in the CPU in most cases, rather than being a seperate chip or
card that can be simply bus-probed or manipulated physically.

> Now think of the typical LUKS application scenario, i.e.  disk
> encryption.  Usually the ones forcing you to hand over your password
> will have access to the disk as well, and, if they have any real
> suspicion, they will mirror your disk before entering anything supplied
> by you.  This neatly negates any Nuke-Option.  If they have no suspicion
> (just harassing people that cross some border for example), the
> Nuke-Option would work, but see above about likely negative consequences
> and remember that a Nuke-Option may not work reliably on SSD and hybrid
> drives anyways.

Disk mirroring is a valid concern, but can be fixed by having layered
configurations, such as: having a outer configuration that decrypts the
inner configuration.
The outer configuration can have keyslots for the hardware security
chips, to decrypt the inner configuration (which includes the keyslot
parameters for the duress password and the normal password, and other
LUKS parameters). Not only does this make it so that wiping the
HSM/TPM/etc. permanently destroys any chance of decrypting the inner
configuration and thus the rest of the hard drive, this may also make it
hard to determine if the hard drive is "booby-trapped" just from reading
the LUKS header.

Why was not such a design considered for this kind of setup? (if it wasn't
due to complexity). Computers have advanced so far after
(persumably) this FAQ entry was written

> Still, if you have a good use-case (i.e.  non-abstract real-world
> situation) where a Nuke-Option would actually be beneficial, please let
> me know.

Imagine if you were being tortured by people to unlock a hard drive that
you didn't want them to see the contents of, and so you give them the
password to hopefully make it so that it wipes the TPM/HSM/etc. of the
computer and destroy any chance of unlocking the contents, thus making
their job futile and saving information from ending up on your
adversaries' hands (even if it meant it cost you your life)