So there's like 3% difference between the two cases, and even that might be just noise. This is consistent with the two indexes being about the same size.
I also don't think we can get great speedup in the mentioned case, so it is not urgently needed of course. My point is that it is just nice to have a multicolumn index constructed on stacked trees constructed on separate columns, not on the index tuples as a whole thing. At least there is a benefit of sparing shared memory if we don't need to cache index tuples of several similar indexes, instead caching one "compound index". So if someone wants to propose this thing I'd support it provided problems with concurrency, which were mentioned by Peter are solved.
These problems could be appear easy though, as we have index tuples constructed in a similar way as heap tuples. Maybe it could be easier if we had another heap am, which stored separate attributes (if so it could be useful as a better JSON storage method than we have today).