Recent versions of Java (Java 8+) avoid structural types but provide structural conversions + inference.
We will see with the recent introduction of named records/tuples goes in the same direction or not.
To be fair, C++ templates are not structural types, they are (together with C++ function overload resolution) an (almost) purely functional untyped programming language, producing C++ programs as output.
Of course, backward compatibility means those are optional, but the designer of the template decides. Existing libraries are all structural, but new ones will rely more on nominal meta-typing, and error messages for those are clean.
There will be pressure to retrofit older libraries, so that error messages from misuses of those get nicer too. Gripes from users who had successfully abused those libraries will be heard.
Nominal typing of generic code would be what most other languages that supports generic programming use. For example Rust has traits where one defines a named trait and must explicitly specify that a type satisfies a trait by name.
In C++ there is no such means, a concept does strictly structural checks (via constraints) to determine if a template satisfies a concept, no names are involved. In other words, a type T satisfies a concept C defined by a constraint R if and only if a T can be substituted for C's placeholder type during the evaluation of R.
For an example see std::tuple_size/tuple_element and their relation with (ironically) structured binding.
In Rust, a generic is only right or wrong, in isolation. In C++, how it behaves, including whether it compiles, depends on how you choose to use it. That makes C++ templates strictly more powerful than Rust facilities. Rust could relax some restrictions, selectively, to gain that power, and might someday.
Preventing the "compiler vomit" is a main selling point of Concepts, and it works. It is still possible to subvert it, if you work at that (then you are no worse off than before). So, don't.
When one works with teams our options don't work in isolation.
As for concepts working in preventing compiler vomit, there is still plenty of work to do in 2021.
There is always more work to do. That is not a failing, it's just life.
That is what defines modern C++, a standard full of political compromises, slowly becoming a niche language.
You wish C++ were becoming a niche language, but in fact its usage is still growing by leaps and bounds, as it has been continually since C++11 came out. Every week more people pick up C++ than the whole population now employed coding that other language. That will be true next year, too.
The fact is that it has become a niche language for GPGPU programing, OS drivers and embedded standards like AUTOSAR, everywhere else another language takes the crown jewels, iOS, Android, macOS, ChromeOS, Windows Apps, Web, cloud computing infrastructure,... where is your growing C++?
So much that Apple and Google are now rather focusing on their own languages, with C++17 being good enough for their own purposes, hence why clang is trailing its ISO C++20 compliance.
When everyone brings their own agenda to the table regarding implementation details it is politics, not only concepts, contracts, ABI breaks (god forbid!), reflection, networking, graphics,...., definitly politics.
But hey, it is growing on GPGPU, HPC, Machine Learning libraries for Python, LLVM/GCC implementation language, so there is that.