E.g. identity verification. My state has a "qualified" certificate that can be used to sign contracts and basically everything else you can do in-person. When you can transfer you home with that, there are higher requirements on checking the identity of a person who gets the certificate.
That CA is not used for much else and is basically confined to our state. But it has to be in Windows, otherwise no other software could verify the signatures.
Why would you want to mix identity verification with the WebPKI? This makes no sense at all. Just because a CA is trusted for web verification doesn't mean it's trusted for identity verification, machine enrollment, or any other purpose. And vice-versa: a CA for identity verification is not in any way trusted for web verification.
I think the idea was to use client certs for strong authentication on the government web services, which didn't rally took off, except maybe in Estonia.
You don't really need your CA doing eIDAS in the system root. This scheme works as a closed system where you need eIDAS app to produce the artifact and another eIDAS app to verify it, when both have their own non-system root.
Ukraine for example successfully operates their own eIDAS-like scheme where everything is based on DSTU+GOST algos not supported by any operating systems a major libraries, the certs are signed by the government root and it doesn't leak into web pki.
It doesn't have to be. In Costa Rica the Central Bank has their own CA for the same purpose. We need to download the certificates ourselves. It is inconvenient, but an error by that CA won't propagate to the rest of the world.
That CA is not used for much else and is basically confined to our state. But it has to be in Windows, otherwise no other software could verify the signatures.
See eIDAS and other similar schemes.