It can't do these things because it's not wanted. Say you have the following:

  enum Value {
      Float(f64),
      Ptr(*const T),
  }

A 64-bit sum type can't magically combine an i64, f64, and several raw pointers, each of which carry a full 64 bits themselves. You have to change the semantics of the code. Some semantics could be expressed more easily with compiler improvements, allowing eg `Aligned<T>` like `NonNull<T>`, or `FiniteF64` like `NonZeroU64`, or even `#[range(0..1<<60)] u64`, but you still couldn't overlap two `Aligned`s in one enum, because only one can be stored unchanged, the others need masking off before usage. Even if the enum semantics allowed this, I'm not sure the compiler should do this kind of compute/memory tradeoff automagically. Which doesn't mean you can't write nice abstractions over it, there's a few tagged ptr crates which aim to do it for you

It's so funny to see a "compiler is magic" people encountering reality in the wild. No, an algorithm that must work for every single user of the language cannot possibly optimize for every individual's use case. It is trivial for hand-written code to outperform a compiler on bespoke use cases. That anyone perpetuated otherwise was a lie they told themselves to feel secure in their ignorance and incompetence, because it's more comfortable to excuse your lack of skill if you believe that no human could ever out-perform a compiler. The saddest part is the barrier isn't even that high. You, and the rest of the magical compiler religious believers, could learn to do this, if only you tried instead of believing in your fairy tale.