I tested the patch and it works ok... While it solves one of the issues noted here: https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Areas
It is a bit awkward to use, I think part of the reason is there is no support for merging an area in two areas like in the image below:

Because of this I found myself getting "stuck", with the patch I was able to get out of this but it was like a puzzle.
I would be against merging this patch without having support described in the image above.

Thanks, @Aaron Carlisle (Blendify)! I'm glad the patch works for you.
While I agree that it is possible to get "stuck", surely it is much easier to get stuck without the patch than with it? (So I don't see why this is a reason not to merge.)
This getting stuck is the reason I wrote it in the first place. The join operations that the patch allows are a strict superset of the join operations that are allowed without the patch.

About the second improvement to area joining that you refer to: yes, I agree this needs to be done. But it's a more complicated task than the first one, both in defining what the correct behavior is, and in the implementation.

For example, what is the correct behavior in this case?

+---+---+---+
|   |   |   |
| 1 +-+-+-+-+
|   | |   | |
+---+-+---+-+

Area 1 gets its upper-right corner dragged to the right.

Implementation-wise, the join operator will need to keep track of more than just two areas, and will need to find areas by different means than just finding the area under the cursor. Also, the code that draws the join overlay will need to be restructured.

In D2576#60342, @Daan Michiels (daan) wrote:

+---+---+---+
|   |   |   |
| 1 +-+-+-+-+
|   | |   | |
+---+-+---+-+

Area 1 gets its upper-right corner dragged to the right.

I can think of two ways to solve this:

• Always use the first set of edges that form the same horizontal/vertical coordinates as the one dragged from - In your example this would be the screen boundary on the right.
• Allow gradually increasing join size edge by edge - In your example this would look something like this:

Initial layout:
+---+---+---+
|   |   |   |
| 1 +-+-+-+-+
|   | |   | |
+---+-+---+-+
Mouse release after dragging over first vertical edge:
+-----+-+---+
|     | |   |
|  1  +-+-+-+
|     |   | |
+-----+---+-+
Mouse release after dragging over next vertical edge:
+-------+---+
|       |   |
|   1   +-+-+
|       | | |
+-------+-+-+
...

Implementation-wise, the join operator will need to keep track of more than just two areas, and will need to find areas by different means than just finding the area under the cursor. Also, the code that draws the join overlay will need to be restructured.

I definitely wouldn't mind a refactor of the area joining code, it's really hard to understand whats going on in it, far from self-explaining. Guess the main reasons for that are bad variable names and cryptic integer and character values instead of enums/defines.
Feel free to give it a go, otherwise I will ;)

Thanks for the helpful comments, @Julian Eisel (Severin)!

About the first bug you mention: This is by design. The old join operator also allows losing track of the initial area, and joining areas far away from it (see screenshot). In fact, the part of screen_ops.c where you say "could you explain some more?" is precisely the part that allows this behavior.
The old code has the following section (a couple of lines lower):

/* we are not bordering on the previously selected area 
 * we check if area has common border with the one marked for removal
 * in this case we can change areas
 */
if (area_jointype(jd->sa2, sa) != NOJOIN) {
	if (jd->sa1) jd->sa1->flag &= ~AREA_FLAG_DRAWJOINFROM;
	if (jd->sa2) jd->sa2->flag &= ~AREA_FLAG_DRAWJOINTO;
	jd->sa1 = jd->sa2;
	jd->sa2 = sa;
	if (jd->sa1) jd->sa1->flag |= AREA_FLAG_DRAWJOINFROM;
	if (jd->sa2) jd->sa2->flag |= AREA_FLAG_DRAWJOINTO;
}

The section you ask about is the partial-join equivalent of this. I can take out this behavior if you want, but I tried both behaviors and to me this feels the most natural.

About the useful names for the vertices: I chose v1, v2, v3, v4 because all the other area-related code uses this convention (e.g. in the definition of ScrArea). If you want, I can use longer names, though, at the cost of having two ways of naming in the code.

About your suggestions for the other flexible join type: yes, those seem like good options. My personal preference is the gradual increase as the mouse is dragged, I think.
(A third option would be to always expand the minimum distance necessary to absord at least one area, which is effectively the same as your gradual-increase proposal with the cursor crossing only a single edge.)

In any case, I probably won't have time to write this second kind of flexible join operation anytime soon. I'll keep revising this first type of flexible join until it's ready to be merged (I haven't put it into the 2.8 branch yet -- btw, what am I supposed to do for this? Rebase on blender2.8 and submit a new diff here?), but after that it's all yours.

Poke.

I feel like the poke is meant for me, but I don't know what I'm supposed to do. I've made all the requested changes, or explained why I think they are not needed.
Is there an "I'm done revising"-button? I couldn't find one half a year ago, and I can't find one now.

No, the poke was mainly for reviewers. Glad to hear that you are still active!

After 5 years of this patch not getting attention, I see this functionality is now in recent Blender releases (https://www.blender.org/download/releases/3-0/ under Area Management). I believe this means this patch can be closed.

For future reference, the relevant patch seems to have been https://developer.blender.org/D8084 (and some of the discussion there exactly mirrors the discussion here).