After installing the new update to better portals 2.4 the linking and coordination between the two worlds are completely out of balance and do not work as the game intends using the 8:1 ratio. I have been using the portals just fine with and without better portals 1.6, as soon as I had updated the linking between my original portals are now random and do not work properly. On top of which when messing around near my previous portals I had already been using properly prior to the bug and creating a new portal in the nether just a few blocks away from the first portal (without exceeding the 8 blocks) it would generate a brand new portal in the overworld hundreds of blocks away in a brand new biome. This doesn't make sense and is clearly a bug connected to this mod. I have removed mods switched them out and downgraded some but the only one to cause this was Better portals 2.4. I'd rather not get questioned if I am placing the portals down correctly or not because I know i am and I know that this has to do with the coordination with the portals in this mod and I'd rather shed light on it rather than scrounge around the internet reading the same thing over and over.

the linking between my original portals are now random

Linking isn't random (or at least it shouldn't be).
First, the coordinates of the portal (when talking about coordinates of portals, that's usually the position of one specific, i.e. fixed, yet undetermined portal block) are converted to the other dimension, then an existing frame of matching shape is searched within some radius (BP does 64 iirc whereas vanilla only does 16; edit/clarification: vanilla doesn't search for frames at all, it uses 16 for the preferred location step) around that location. If one is found, it is used. If multiple are found, the one with the shortest euclidean distance is used.
If no frame is found, then the closest (by euclidean distance) preferred spot is used to generate a new portal frame. A preferred spot is one which has pre-existing ground and no blocks in the way (slightly more complicated for lying portals).
If no preferred spot exists either, then the portal is placed at the exact coordinates determined at the start, replacing whichever blocks where there before.
You can find the implementation of this algorithm here.

This doesn't make sense and is clearly a bug connected to this mod.

No. Let's take this step by step (with example coordinates):

1. You had previously built a portal at 0/10/0 in the overworld
2. The matching coordinates in the nether would have been 0/10/0, however there are blocks there, so the closest available space is chosen instead. Let's say that's at 20/10/0 (well within the 64 block search radius, even within vanilla's 16 radius)
3. You build a second portal in the nether, near the existing one at 26/10/0 (within 8 blocks of the other one)
4. The matching coordinates in the overworld would be 208/10/0 and since no portal exists, that's where a new one is generated, i.e. 208 blocks from the first one
   AFAIK the same thing can even happen in vanilla with one and the same portal (because vanilla doesn't remember links).

I'd rather not get questioned if I am placing the portals down correctly or not because I know i am

I disagree, see above.
That doesn't mean that there isn't any bug (there have been in the past and relevant code has changed recently when CubicChunks support was added), it just means that you'll need to tell me exact coordinates of where you put down portals and where they ended up linking to.

Correction they aren't random or at least they are offset I should say
The search radius works they are just offset and the putting down a return portal within the matching search radius(for testing purposes) you'd think it would take you back to the portal you used to enter the nether but it would spit you out at a completely new location regardless if blocks
aren't taking up space in the exact matching coords.

I would rather show you what I am trying to explain rather than discuss it over github. I will make a clip using 1.6 to show that it works as intended and a clip of 2.4 to show you the problem that I am trying to illustrate maybe you'll get a better understanding of what I mean.

I am not disregarding your knowledge of the mod or how it works with the vanilla portal mechanics, you made it I am just trying to show the mini problem that had risen upon the update.(its a genius mod and should be implemented in the base game)

First vid without problems
https://www.youtube.com/watch?v=nciQAKG4lLk&t=32s
Second vid with problems
https://www.youtube.com/watch?v=nS5EyS7gRAU&t=2s

Thanks for the video, took a mere minute of watching the second one to realize what's wrong.

And you're right, there's indeed a (really stupid copy/paste) bug in the portal searching code which snug in while implementing CubicChunks support.
It limits the actual search area to be just one block wide in z-direction (at a -64 offset from the expected coordinate). It also only happens when CC isn't installed which is why I hadn't noticed during development.

Since it's quite severe and not difficult to fix, I'll get right to it.

Awesome I'm glad the post was able to shed light on this little hiccup in some way, but most importantly thanks for the overall assist with the issue.
c: