It can be solved - probably fairly easily. When mouse cursor is not over a panel or button, input falls through to the underlying viewport.
Someone just has to do it.
Core developers are in bug-fixing mode currently, so these kinds of issues aren’t being worked on. If anyone from the community is willing to work on it, that would be great.
If not, hopefully it will be tackled before release.
IMHO almost all the confusion with those side panels comes with the combination of region overlap when also using an opacity of zero for region background. If you set the opacity to something that makes it even barely visible then the behaviour makes sense. I’m not certain we can, or want, to make it work differently if opacity goes under a visible threshold.
There is a big advantage in having the opacity be zero there. A lot of screen space is regained. And even if opacity is non-zero, input could still go to viewport underneath.
Here are some screenshots to illustrate. Both with region overlap but the left has zero opacity while the right is non-zero.
On the bottom of the left side it makes sense that users are confused. The panel resizing will seem to extend past the panel size and ctrl-drag resizing seems to affect the wrong region.
But set like the right that confusion is gone. There is no idea of resizing below the region because it is that long. And it is that long because all the sub-panels can be expanded. Region resizing also makes sense to do in that area.
So I’m not certain how fix the behavior so it makes sense as you change opacity…
Everything seems simple to implement except what users ask for. We are still waiting for it to become optional to have the tool settings menu in the sidebar and put it on the left of the activetools.
I guess it’s simpler to just turn off. 
And again, I am not saying we should get rid of zero-opacity on these regions. I’m am just saying it is hard to think of a changed behavior that works along the spectrum as you change opacity.
As an example, here is another screen capture. Still with “region overlap” on, but with a much higher opacity:
How do we treat the region below the collapsed panels? Do we not allow the region to be resized for its bottom 3/4? How do we explain to users why they cannot? Do we also not allow region resizing there? Why?
Either we can accept that in the case of fully opaque, it seems a little bit strange that input falls to underlying view. It might not be so bad given that the default is for it to be transparent.
Or we can use some sort of heuristic like if < 50% opacity, then let input drop to layer below.
I think the first option would be acceptable and a better overall compromise than the current one. The second option I suppose is ideal but more complex
Ahhh great thank you 
uncommon way but better than nothing.
Another example, with region overlap on and with opacity set to only 0.18 - how visible it is depends on the colors of the two overlapping areas.
In this case why should this resize not work? Would users not complain about this too?
See above - same applies for that.
I did read your comment above and can’t guess from it how you would deal with this last example.
Are you saying that the left-right panel resize (that allows you to go to two columns or show text label) should not work where I have illustrated?
Yes, otherwise it will appear in thin air, as it does currently, which doesn’t make any sense. Again, we could add a heuristic, like it only appearing with some opacity threshold, or not.
Because… if you answer is “yes”, that doesn’t end the complications…
Here are two captures, before and after the region changes from one column to two. If the resize only works where there is content in the region, then what happens as it changes?
So on the left that drag was too low, so we make it not work and ignore use complaints there. But it does work if you move up slightly, but then after the drag the area that did work suddenly does not?
You can just drag on the part where the actual toolbar is?
So you place your mouse in a position where there is content in the region, as shown on the left below. You drag to the right so the columns increase to two. You change your mind and try to drag it back, but it no longer works from there?
This bit again:
In 2.79 it looks like:
where the active area in the corner for splitting regions is visually indicated. Also in 2.79 it’s just the upper-right and lower-left corners that are active and labeled in this way so there’s no way you can grab the wrong side.
In 2.80 all the corners are active and none of them have any visual indication of the active area other than the + cursor.
So the problem comes when a user is trying to act to split or merge two regions using the mouse. Because there’s no visual indication that what you’re really doing is grabbing a corner of the window, the eye is drawn to the point where the two regions meet (the very top of the vertical separator bar) and indeed if you point at this area the mouse cursor changes to a + but whether it works or not in the way you expect depends entirely on whether you’re clicking to the left or right of the center point, and if you get it wrong it will seem like it’s not working right. I have seen this be quite frustrating to people until you explain that they should instead aim for the corner of the window they want to affect.
There’s only like a single pixel width to the vertical separator bar drag area at the top, so it’s easy to entirely miss that it’s not a single active area for the + icon, and again as you’re drawn toward the center it’s likely that you may click on the “wrong” side about half the time.
So, in addition to the + cursor, could we possibly have the active corner area of the region highlighted when the mouse is over it, thus indicating both the active area and which region it’s associated with?
Or can we replace the single + cursor with four separate little arrow cursors pointing into the region whose corner you’re going to be clicking?
Alternatively if we just move the active areas a bit farther apart so that it’s more obvious that they are separate things that would help somewhat.
I can see how that would help with the placement of your cursor at the corner, but arrows might not make sense. The actions you can do from a single corner could be to split that same area (in one of two different directions) or to join with an neighboring area. So arrows don’t seem to tell the right story about possible future action. Any other ideas for the cursor that might work better?
How about if the cursor changed into a solid triangle shape, so similar to the old visual at the corner? That way it wouldn’t be implying a particular action, but would change as you move between areas at the corner.
Yes. That is preferable overall yes, especially when the toolbar has no alpha.
Yes, it has been pointed out to me that this is a pending potential patch:
https://developer.blender.org/D4264
so hopefully soon!
