1. I think you mean the "glibc" resolver, not the "glib" resolver (I do not believe that GLib contains a resolver).
2. systemd-resolved does not use glibc's resolver.
It is true that systemd-resolved does not understand root queries, and it is unfortunate that the systemd maintainers seem to be unwilling to add support https://github.com/systemd/systemd/issues/5897 . However, this has nothing to do with it using glibc's resolver.
However, as clearly documented in the systemd-resolved(8) man-page: There are 4 supported modes of operation with regard to /etc/resolv.conf, which each have different trade-offs, and are configured by changing /etc/resolve.conf itself:
(1) symlink to /run/systemd/resolve/stub-resolv.conf
(2) symlink to /usr/lib/systemd/resolv.conf
(3) symlink to /run/systemd/resolve/resolv.conf
(4) regular file
`dig +trace` should work properly in modes (3) and (4).
The big difference between those modes is "how do you want programs that don't use the system APIs (and instead do DNS themselves) to behave?". Modes (1) and (2) say "have them send their traffic through systemd-resolved", which as you note has some deficiencies; modes (3) and (4) mean "allow them to talk to the remote DNS servers directly".
Just to add, since I didn't speak about the differences between (1) and (2) or (3) and (4):
You have to use (4) if (and only if) you're going to use a resolvconf(8) implementation other than systemd-resolvconf. For example, I use dhcpcd; for kinda silly reasons dhcpcd and systemd-resolvconf don't work together, so I'm stuck using openresolv as my resolvconf(8) implementation. So I have to use (4). If you're fine using systemd-resolvconf, you should use one of the other 3 modes.
I'm honestly not sure why you would ever use (2) instead of (1). It's like (1), except search paths won't work right for programs that don't use the system APIs. (Maybe it existed before (1) did, and still exists for historical compatibility?)
Probably because the main dev "knows better". Looking from the outside at common complaints across systemd, there seem to be plenty of weird defaults that hurt power users, with that being the primary reason behind not changing it to something more standard.
It's a situation where you can't do the right thing in all places.
Some programs, like statically linked Go programs, don't use the system APIs because they don't want to link against external libraries. So, if the system is configured to use mDNS for .local hostnames (either via systemd-resolved or via nss_mdns), those programs will mysteriously do the wrong thing, because they _only_ speak plain DNS. You can hack around that, and get them to do the right thing, by having a stub DNS server that they talk to, and have that stub server fire off mDNS requests instead of DNS requests as appropriate. Similar story for things like DNSSEC or DNS-over-TLS. That's what modes (1) and (2) do, they make statically-linked-programs that would otherwise use the system APIs do the right thing.
Other programs, like `dig`, don't use the system APIs because the really do care about speaking DNS directly. They just need the list of DNS servers to talk to and search suffixes to use. Giving them that is what modes (3) and (4) do.
It's literally impossible to keep both sets of programs "doing the right thing" at the same time. So the question is: which group of programs do you want to do the right thing? The systemd devs don't know (much less "know better"), so they made it configurable. Which one is default is up to the distro, not systemd.
2. systemd-resolved does not use glibc's resolver.
It is true that systemd-resolved does not understand root queries, and it is unfortunate that the systemd maintainers seem to be unwilling to add support https://github.com/systemd/systemd/issues/5897 . However, this has nothing to do with it using glibc's resolver.
However, as clearly documented in the systemd-resolved(8) man-page: There are 4 supported modes of operation with regard to /etc/resolv.conf, which each have different trade-offs, and are configured by changing /etc/resolve.conf itself:
(1) symlink to /run/systemd/resolve/stub-resolv.conf
(2) symlink to /usr/lib/systemd/resolv.conf
(3) symlink to /run/systemd/resolve/resolv.conf
(4) regular file
`dig +trace` should work properly in modes (3) and (4).
The big difference between those modes is "how do you want programs that don't use the system APIs (and instead do DNS themselves) to behave?". Modes (1) and (2) say "have them send their traffic through systemd-resolved", which as you note has some deficiencies; modes (3) and (4) mean "allow them to talk to the remote DNS servers directly".