I am still proceeding in the same direction I originally discussed in the previous post.

Internal cuboid loading and cuboid keep-alive will allow for the portal to load its target and should also avoid load/unload thrashing around cuboid boundaries (just due to the keep-alive timeout - no other cleverness).

There are still questions about some of the details here:
-if the portal is a composite (new thing, as opposed to a cohesive multi-block), is this just the frame or also a portal "surface"?
-should the "portal surface" even exists as a logical block or is that just something the client should draw when a "portal frame" is active?
-should the portal's output location be stored as some kind of special aspect or should it be a property of an item which is stored in a new "special inventory aspect" (this sounds like over-design but could be used in some other cases like enchantment or item filtering)
-is this "polling solution" to verify the target location (and potentially composite block structure validity) acceptable or is this just an ugly hack to avoid a more complex event-based solution?

My current thinking around how to approach this:
-create the idea of a "composite structure" (a keystone block determined valid by a certain arrangement of other blocks around it), for the portal frame, and use a polling validity check for this (every 5 seconds?). This is kind of a hack but it isn't obvious if an event-based solution could be defined, based on how blocks can be spread across other cuboids (although some kind of "on load" mutation registration might make this work). However, this polling solution will work for the near-term, at least (and the target polling is likely even less avoidable, anyway)
-an active portal will be a multi-block (this is to avoid special-cases on the client and avoid other blocks displacing this one)
-portal surface multi-block will be set or removed by the keystone when target is found valid/invalid
-the portal frame keystone will implement polling for these actions: (1) check frame composite structure, (2) check target location (target is keystone and valid composite frame with non-solid blocks inside) including keep-alive, (3) teleport any entities in the portal surface multi-block to the target keystone (probably make sure these are seen for 2 consecutive polls using ephemeral data)
-keystone target location will be set by containing a "bound mana stone" in a new "special inventory" aspect

An annoying problem I still need to figure out (well, not "need", but "should") is the keep-alive loop: Bidirectionally bound portal frames will keep each other loaded forever, even if no player is near either. I have some ideas (make a portal should check that there are players within a certain range before sending the keep-alive), but I am not sure that this matters for the next release as this is a very small problem.

More prototyping required on this composite structure, special aspect, and bound locations,
Jeff.