In 18.2, we updated the conveyor roller skew kinematics to be based on item travel distance instead of time. This bug is being caused by a part of the code that wasn't updated properly to use distance instead of time for the kinematics.
I've fixed this bug for the next bugfix release.
For the time being, you can mostly work around the issue by using an entry transfer into the skew angle conveyor instead of an in-line transfer:
A-connect the upsteam conveyor to make Exit and Entry Transfers,

Then delete the in-line transfer. (Selecting that transfer is difficult, but it is easier if you put the view into a Perspective Projection.)

See the attached example. 19249-skew-workaround.fsm
This will make it so that when the code incorrectly uses the time (instead of correctly using the distance) to prune the roller skew kinematics, the kinematics calculation starts from 0 to the end of the roller skew conveyor instead of including the distance along the upstream conveyor.
This workaround isn't perfect; there are still moments near the beginning of the model run where an item may jump incorrectly because the current model time is a very low value, but it should help mitigate the issue.
When the model units are in meters instead of inches, it accidentally hides the issue for the same reason as why the workaround helps. The problem only manifests itself early in the model run, and with meter units, the time when it starts working correctly is earlier than with inches units.
Phil BoBo
Sr. Manager, Software Development