Itanium's major sticking point was relying on compiler technology that never materialized. The Mill architecture seems to respect the current level of compiler tech a lot more.
Itanium was a VLIW and the Yale Bulldog compiler solved the VLIW code generation problem with trace scheduling back in the 80s. At this point, that's standard Dragon Book stuff.
Itanium failed to be sure but it wasn't the compiler. However I'll grant that the workload didn't match the EPIC architecture and the compiler. EPIC succeeded at scientific workloads.
As to whether Mill respects the current level of compiler tech a lot more I'd like to know more about that. They need to get their LLVM backend up and running.
The Mill's history may be different because compilers actually advanced a lot since Itanium's launch, because it brings some arguably improvement over Itanium, or because the Mill's team is trying to write those compiler improvements, instead of making a partnership with Microsoft.
I don't know, some of the novelties in the Mill arch would seem to simplify compilers. For instance, no need for complex register allocation.
Other optimizations applicable to traditional CPUs either may not apply to the Mill CPU, or may need significant tweaking to work properly.
The one thing that I think makes the Mill simpler is the no-value values mixed with lazy error conditions. I have no idea if those are powerful enough to compensate the rest.
For spilling: if a desired argument is less than one belt-length away then we directly reference it; between one and two away we reorder; and more than two we spill.
We place a load as soon as the address arguments are statically available. The compiler doesn't have to deal with aliasing, which is a large and bug-ridden part of compiling for other targets.
Lazy-error (aka NaR) means that there are no error dependencies in arithmetic expressions. Current compilers for other targets simply ignore such dependencies, relying on the "undefined behavior" rule. Mill is designed to not produce nasal demons :-)
Incidentally, I don't think the Itanium compiler tech never materialized, it just materialized late. Itanium had a lot of other problems, but the later Itanium models really flew for certain workloads (SQL Server, in particular). After the first one (which was quite a dud and killed Itanium's reputation), Itanium was definitely not slow. The x86 emulator was slow, and AMD64 absolutely stole Itanium's lunch.