Disclaimer: all info, videos and images were captured in fabric. However, the behavior has been confirmed by myself and others to also happen identically in vanilla 1.17.1.

Bug in question shown in video 1.

In the setup shown by images 1 - 4, after the entity gains velocity as described in image 5 (data collected via /data get entity @e[type=item,limit=1,sort=nearest] Pos and Motion and CarpetMod's /tick freeze and step 1 commands), it 100% of the time collides with what I can only guess is the fence's hitbox.
But it shouldn't. By further examination via F3 + B, the item entity hitbox doesn't collide with the fence's, and if that were the case, the item entity would be expected to collide with both fences simultaneously and get stuck, instead of launching off the water stream.

Also should be added that the launching direction depends on the water flow direction:
North oriented streams (-east and -west) have their item entities launched north, and south oriented streams launch their item entities south (consistency tested via Save and Quit to Title).

As well as that, the item entity only gets deflected if the block located where the fences are (which are used to contain the water stream flow) has a hitbox of at least 4 blocks diagonally perpendicular to the stream's center diagonal, examples of this are fences and sea pickles, meanwhile this behavior isn't observed with glass panes, which has a diagonal hitbox of 2 pixels.

Images 6 and 7 show further testing, by showing setups in a northwest oriented stream with which the item entity doesn't get deflected at all (by having a sea pickle placed north of the stream's center diagonal, image 6) and with which it gets deflected north (as discussed previously in regards to stream orientation, pickle placed east of the stream's center diagonal, image 7).

By image 5 and Pythagoras' Theorem, the equivalent diagonal velocity a tick prior to collision was calculated as approximately 0.79898. I feel like there should be an investigation regarding whether the diagonal speed threshold of 0.8 has any effect on the item entity.

Added world download for easier testing and showing hitbox limitations.

Upon further testing, I determined that the same bug occurs using glass panes (which was previously stated to not happen). For that to be the case, the same setup needs to be expanded 79 blocks diagonally counting from the light blue stained glass block. The measured equivalent diagonal speed was calculated as approximately 0.91824 (note: even with "perfect" alignment, at this distance the item entity does end up misaligned enough for it to be noticeable via /data get entity @e[type=item,limit=1,sort=nearest] Pos on it's last shown digit, however the Motion argument doesn't show the same noticeable change, thus the abrupt change in the velocity vector shouldn't be expected).

Code Analysis by PR0CESS here