A quick conversation with lordheavy reveals that a dri backend is required by mesa (swrast), and that can apparently be satisfied with the dri1 drivers in community, so the split is necessary and mesa must depend on mesa-dri.

As for mesa-dri not automatically pulling mesa-libgl: First, it can't because of the above statement. If it did, nvidia users wouldn't be able to install mesa at all. Second, I don't see the problem with having the user choose the package when something pulls the libgl virtual dep.

I can understand why mesa-libgl isn't pulled by mesa-dri if mesa must dep on it. But I don't understand what's the relationship between the necessity of the split (of mesa and mesa-dri, i suppose) and the dri1 drivers. The only reason I saw for the split is the dependency of mesa-dri on mesa-libgl.

And I would suggest having the swrast backends in mesa and other vendor-specifc backends in mesa-dri for that. While some may argue that this mixed up the nature of the packages or something, I found it fine to have such general/fallback backends in the mesa package.

After some thought I realized that a better approach might be the xf86-video-* which deps on mesa-dri should also (or probably instead, then mesa and mesa-dri can be merged) deps on mesa-libgl. Btw should mesa-dri1 even provide mesa-dri (unless they can really substitute the swrast backends)? Also i810 should probably be an optdep of xf86-video-intel.

NOTES:
1. mesa and mesa-dri is merged (mesa pulled mesa-dri anyway; even though dri1 packages "provides" mesa-dri, you can almost never skip the installation of mesa-dri)
2. xorg-drivers pulls mesa-libgl which pulls mesa (mesa-libgl would be the only correct libgl to use; they all pulled mesa-dri which ultimately pulled mesa (see 4); may also take nvidia and bumblebee packages as reference)
3. i810-dri is added as an optdep to xf86-video-intel (i'm not sure if this is correct, but the description of xf86-video-intel consists of "i810")
4. libtxc_dxtn no longer deps on mesa to avoid cycle deps caused by the merge (unless somehow it should dep on mesa anyway; mesa-dri pulled libtxc_dxtn which pulled mesa)

Hi Tom,
I believe that you can blame me about the current state of things (see  FS#41912 ) :P
Afaics you've followed the dependency chain by explicitly stating the connections, but no actual issue is mentioned.

Well I don't blame you :P

Probably there won't be big issues for user otherwise I'm sure tons of people would "agree with" me here.

But I just see no reason for the current chain/split. I find things like "I've installed my xf86-video-*, and now I have to install/pick mesa-libgl explicitly" pretty dumb (especially in fine Arch), because you would never want nvidia*-libgl when you are using the foss driver (just like the case of bumblebee, which is the only thing explicitly deps on mesa-libgl now). So why should the user need to pick when there's no reason to make it work this way?

Also, "there are mesa and mesa-dri, but i always end up have them both installed", so why the split?

P.S. Well I'm aware that someone might want to do non-sense like this though: https://wiki.archlinux.org/index.php/Nouveau#Keep_NVIDIA_driver_installed :|

Why the split - if it's up-to me mesa package will still be split into libglapi, libgbm... etc.
If others strongly feel about merging mesa and mesa-dri so be it - it's a bit too much imho but I'll survive.

If you install xorg-server or any game that depends on libgl, it automatically prompts you to choose from mesa-libgl and nvidia-libgl. I'm not sure why/how one needs to manually pick it ?
Can you point out a clear chain of things that you have in mind ? I.e. installing XXX, yet YYY and/or ZZZ are missing, thus I need to manually install them.

I would not call switching between nouveau and the blob a nonsense, but I don't see any problems with it and the current packages:
$ pacman -Rdds mesa-libgl && pacman -S --asdeps nvidia-libgl (and vice-versa)

To me split only make sense if they won't end up pulling each other, and it allows certain conflicts to be resolved. It's not like "oh they have different components let's split them all...hmm they have to dep on each others, but nvm let's do it \o/"

By pick I mean "choose from mesa-libgl and nvidia libgl", it's not a big issue, but it's silly. The thing is I see no point of the prompt, when they got the ddx installed it should have pulled mesa-libgl, because it's impossible they would want nvidia-libgl except when they want what I called non-sense.

By non-sense I didn't mean the switch, but the way to switch or desire to keep part of nvidia and use nouveau.

Anyway I've really talked about this too much. Perhaps I'm too bad at how to present my ideas or simply no one thinks that these matters. So if you don't get it just leave it, I doubt if the devs have any desire to implement this anyway.

P.S. Though I admit that somehow lib32-libtxc_dxtn only makedeps on lib32-mesa, so lib32-mesa-dri won't end up pulling it. I've been curious why the mesa split packages (except mesa-libgl) doesn't dep on mesa anymore, would they even work without the main mesa package?

Phew let me put it this way:
Which libgl does one want depends on what driver does he use. So after one has decided and installed the desired driver, it's dumb for him to be prompted "which libgl do you want" (except in case of multilib, which might not be ideal but can be accepted).

You may argue "but libgl isn't required by everyone, this is Arch so let's them to do it on-demand" <-- No, it isn't, but while it wouldn't cost any extra deps (because the ddx already need to pull mesa, which is its only dep) and it's only symlinks, is there really a strong reason not let the ddx pull(choose) it (considering the dumb prompt I mentioned above)?