I spent the last couple of hours running tests to try and narrow down the issue and hopefully come to some resolution. I appreciate the comments from everyone - they helped me in thinking about the tests and the results. Here are the tests and what I found.
Tests 1, 2, and 3 were run to hone in on the exact speed at which the issue occurs or ceases to occur. It appears that 113 mm/s fails and 114 mm/s succeeds.
Test 4 was run to confirm by alternating back and forth between 113 and 114 mm/s. Tests confirm the boundary.
Assumption: software issue, since it is so consistent.
However: An interesting thing to note here. The point of origin is always the upper left corner of the left-most block. The blocks are run one at a time from left to right. That means they should all be aligned at the top. As you can see, they are not. In fact, the top of each block (2...5) is exactly 1 inch above the bottom of the preceding block. If it is a software issue, meaning the software is intentionally (for whatever reason) rasterizing differently at speeds less than 114 mm/sec then it should know where it is and return to the correct y value to start the next block. But it obviously THINKS it has traveled 1 inch in Y, then it returns 1 inch in Y to start the next - thus "moving" the starting Y position of the next block exactly the distance it DID travel PLUS the distance is did NOT travel in the preceding block.
It could still be a software issue - of the "bug" type - meaning it does not know it is doing it.
Test 5 was a repeat of test 4 but done after I updated my DSP software with the latest version just released last week. The results of test 5 were identical to test 4, so the new software did not help.
Test 6 was run to determine if I can compensate for the loss of steps. It appears I can. The DSP software allows you to, when engraving a vector object, to set the distance between scan lines. By default, that distance is .10. That is what all the previous tests were run at. In test 6, I ran the 113 mm/sec blocks at a scan rate of .09 and the 114mm/sec blocks at .10. While they are not perfectly matched, they are visually close enough. So the solution is likely to be that I have to run make adjustments when rasterizing vectors, based on the speed I am rasterizing. Most of the time, I can run above 114 mm/sec without issue, but some materials require a slower processing.
I will send my test files and results to Marco, so he can pass it on to the engineers. I doubt that they are aware of the issue.
When anyone else gets the DSP up and running on their 2x, it would be interesting to see if you can duplicate my results on your system.
Thanks, again, to everyone who took the time to think about the issue and come up with some helpful comments.