The ordering requirement is indeed the biggest problem once you have structs with more than a handful of items (maybe one day Intellisense will help with this problem), but the missing array access and not being able to "chain" designators (.a.b.c = ...) are also painful omissions.
Clang has demonstrated long before C++20 that it is possible to use the full C99 designated-init feature set in C++, so I really don't understand why the C++ Committee had to cut down the feature when there was already a fully working implementation.
PS: as an example for where C++20 designated initialization breaks down, see for instance [1], I tried to replicate this code in C++20, but quickly gave up (with the main problem being that it is impossible to remember the correct declaration order in big "option bag" structs like this.
[1] https://github.com/floooh/sokol-samples/blob/e0a93a21b17a663...
that's a pretty harsh take on it - how would you design it considering that initialization order has to be respected (else a lot of use cases would break; it's definitely not uncommon to have a member of a struct to depend on a previous member being initialized) ?
I have yet to find a particularly blocking use of the feature when test-driving it - it's on the other hand a great boon for readability (and definitely puts a nail in the coffin of named function parameters proposals imho).