Fast non-projectile entity movements may fail to apply block effects from blocks around the starting position when moving in positive directions

Fast (>= 0.99999blocks/gt in an axis) non-projectile entity movements may fail to apply block effects from blocks around the starting position when moving in positive directions.

Test Setup (first image):

Observers powering redstone lamps and facing string.
Command blocks on both sides with the following commands:
left: /summon minecraft:item ~ ~0.6 ~ {Item:{id:"glass",count:1},Motion:[0,1.04,0]}
right: /summon minecraft:item ~ ~-0.9 ~ {Item:{id:"glass",count:1},Motion:[0,-.96,0]}
Note: Gravity is applied before the items move, so the actual move happens with 0, 1.0, 0 and 0, -1.0, 0 b/t velocities respectively.
Press the button to trigger the command blocks.

Expected Result: Both string should detect the item entities passing through.

Observed Result: Only the downwards moving (right) item entity triggers the string.
Note: This is most pronounced if the blocks around the starting point have non-full block EntityInsideCollisionShape - e.g. string and 1.21.5 nether portals. This is because an entity can move into the gap in the block space where it would not trigger the check in the prior move but then move through the block later on.

To replicate with blocks with full EntityInsideCollisionShape, the entity needs to be created inside the block or the block must be placed in between entity moves.

Code Analysis:

In addCollisionsAlongTravel- which is called by checkInsideBlocks calling BlockGetter.forEachBlockIntersectedBetween (if the movement is faster than 0.99999 blocks/gt) - the game tries to find the intersection point of the line going from the “minimum corner of the bounding box of the entity at the starting point to the minimum corner of the bounding box of the entity at the completion point” to the current block space of the raycast [which roughly travels along the “minimum corner line”].

The game then contracts that intersection point inwards towards the checked block and then iterates through the blocks between the contracted intersection point and that point plus the size of the entity hitbox.

The problem arises from the direction of expansion being always positive [+x, +y, +z]. Which means that if the direction of travel is positive [+x, +y, +z], the origin block will not be checked because the block search will expand in the direction of travel and not backwards as in the case of [-x, -y, -z]. This means that the blocks around the starting position may not be checked.

Also note, even in the correct case where the origin block is being checked, the order of the tripwires activating may be counterintuitive since the “next block” is checked before the “starting block“ - see 2nd image.