This is on Multiplayer, so some of this happened before me. I'll clarify ahead between personal observations from assumptions & information I was told.
Also, I have a guess I'm not the first to encounter this, but a quick search didn't bring up relevant results. Moreover, the information on the wiki indicates that what we're encountering should not happen, so I suppose if the wiki is correct then it would justify the lack of others facing our problem, but for us, the wiki isn't working as noted.
The simple story is about three/four nether portals. A is in the overworld, it leads to B in the nether, but B in the nether unexpectedly leads to C in the overworld, and breaking C makes B lead to D in the overworld. The presence of C and D is undesirable, more so that the wiki's math says they shouldn't exist.
The noted portal information is all observations, and another observation is that D is auto-generated. I was told (and it looks that way) that A was constructed first & manually, and no one has reason to believe B was manually constructed. C is also very unlikely to be manually constructed, so it seems like all the portals came to existence in their alphabetical order, with only A being manually constructed.
I'll be quoting the wiki below, doing its math, and listing my coordinates, maybe I'm using it wrong:
First of all, the game takes the coordinates of the entity who starts colliding with a portal.
The game then converts those coordinates into destination coordinates as above: The entry X- and Z-coordinates are multiplied if the entity is in the nether or divided by 8 if the entity is in the overworld, while the Y-coordinate is not changed.
The Java floor() method used in these conversions rounds down to the largest integer less than or equal to the argument (toward smaller positive values and toward larger negative values), so a coordinate of 29.9 rounds to 29, and one of −29.9 to −30.
Calculations will be based on northern portal coordinates, which is the Z-coordinate with the most absolute (sign ignored) value. Seeing the portal frame is solid, one can only squeeze towards it to deviate by only 0.2 blocks from the center of the standing block, with the noted center being some integer plus 0.5. Per described math:
Portal A should point to (101, <Any>, -38), (6, <Any>, -3).
Portal B should point to (680 to 688, <Any>, -216 to -222), (42 to 43, <Any>, -14).
Starting at these destination coordinates, the game looks for the closest portal point of interest (POI). That point of interest can be within 17×17 chunks in the Overworld and 3×3 chunks in the Nether centered on the chunk containing the destination and the full map height.
Per this, portal A and portal B can theoretically search each other just fine, seeing that portal B is just off by at most 1 chunk in each direction, and portal A is off by at most 8 chunks. Despite this, the game cannot find portal A when entering portal B.
Portals try to link up at their ideal location calculated by Overworld (X,Y,Z) <=> Nether (X/8, Y, Z/8). If no portals are exactly there, the game searches a certain range to find a nearest, active portal. The range used in the nether seems to be a radius of 128 (a 257×257x255 box) or 17x17 chunks (272x272x255), while in the overworld it seems to scale by 8.
This one just seems uncertain on the calculation method. The second method just seems quite generous and things would immediately work, if it is even the active method... while the first method could possibly fail if the lower range of X-coordinates of what portal B would point to were used, but seeing the X-coordinates of portals C and D suggests the lower range wasn't in use for their case. I suppose if the 128-block search radius was circular/spherical, the failure would make sense, but the very paragraph always speaks in terms of rectangular/cuboid, which suggests against said approach.
For coverage's sake, even the "Nether Portal" page mentions the 128-block rule:
If there is already an active portal within range (about 128 blocks) in the other dimension, the player appears in that portal.
Although the very same page lists the following under change-log of version 1.15, snapshot "19w36a":
Search for an existing portal to connect to is now chunk based: the searched area is now 17×17 chunks instead of 257×257 blocks
Which just puts less confidence on the 128-block rule, which should've worked to begin with unless the current location of portals C and D don't precisely indicate the reference point to the calculation to the 128-block rule.
Sooooo long story short, portal A leads to B, but portal B doesn't lead back to A, it instead leads to C, or D if you break C. The math says C and D shouldn't exist, but they do. I'd like to understand my mistake in the math, or the mistake in the wiki, or if the entire math there is just un-credible.
I built a portal at 811 62 -303/-304 (A), used it to go to the Nether, broke the destination portal and built one at 85 107 -26/-27 (B), entered that and ended up at a new portal at 678 64 -218/-219 (C)
I'm guessing this is the video you're referring to. Unfortunately I didn't get to watching it yet, partially due to the length & its general aim, but hopefully I will soon.
Interestingly, I noticed the problem was self-resolved today. I actually broke the incorrect portals for their obsidian, then traveled to & from the nether banking on them re-generating for more obsidian, only to find myself at the original portal, and things working as expected this time.
I recall long ago the wiki had a reference to "a portal remembers the portal that led to it for X amount of time", but I couldn't find that right now. I decided to test in any case, and AFK-ed above 10 minutes in the nether, and the return trip still led me to the original portal.
no, it's not wonky. Portal-pairing only happens for 60 seconds after you last entered a portal, it's there to avoid all the expensive dimension loading/unloading stuff that involves looking for nearby portals.
Well, for starters it's not on the wiki, not anymore at least, and trust me, I don't mind believing in either directions, just as long there's good confidence in said belief, usually due to references or testing.
For seconds, as noted before I waited above 10 minutes, so pairing should've been off, so it wasn't interfering with that result I hope.
Unfortunately though, at some point after the "successful" incident(s), portals started trolling again. Non-determinism seems certain I guess (kinda what I meant by wonky, code doesn't re-write itself after all).
If portal pairs are just on the border of being too far apart you can sometimes get a portal where entering the left side gets a different result than the right side. (And if entering the left side takes you to an existing portal and entering the right makes a new portal then the new portal might then be the closest to the left side as well.)
I'll admit the last incident reported occurred unexpectedly and as such I didn't make a mental note of which exact side I entered/exited. However, in the original test set my entry side of choice was in favor of avoiding the inconsistency, yet it happened.
I had ignored noting down the decimals in testing though. I wonder how relevant or not could that be.