This linked article from a related question explains pretty well the problems with full disk encryption (FDE) and why it "sucks".
TL;DR: It can't be fully randomized, leading to confidentiality problems, because it works on sectors whose tweaks remain constant for each sector and inner offset; it's ignorant of any higher level context / metadata & thus can't authenticate or use such as further randomization; it doesn't bother to authenticate data at all, let alone metadata, leaving it open to many well known attack vectors; and, it's inflexible.
As far as I know, there isn't a type of disk which includes native sector-level modification timestamps or MACs. If they did, I'd assume the randomization problem could be solved by injecting the timestamp as part of the tweak somehow. A native sector-level MAC could be better, as it would function like an SIV, helping to alleviate some randomization and authentication problems (though it would be a MAC of the plaintext, leaving other problems unsolved, including potential loss of data in the case of disk corruption).
TL;DR #2: The FDE problem is a pain in the metaphorical salt, that's kind of a last (and often weakest) line of defense, and which isn't really solvable at the sector level with the kinds of disks which are available on the market, nor without space overhead. What's used in practice is some combination of the following, depending on the needs of the user: Full-Disk Encryption as a line of defense against physical device seizure, filesystem encryption which functions like the former but has more flexibility in what it can do, the space it can use & the context data it has available, filesystem formats which handle integrity & error correction (special shoutout to ZFS), data redundancy to recovery from disk corruption, and application-level encryption for context-rich & context-specific cryptography.
