So maybe its an imperfection that is rightfully annoying but not really crippling the instrument in most practical uses? That would of cause be good news! In any case: do check out how things work in practice and see if things work as they should.
Sure... it's a bug that you will only run into in very VERY rare circumstances... sure I can live with it, but I do think that it's best that the users know about it, so that they can avoid it.
To me it's not really an issue (except for the knowledge, so that I can take it into acount when doing the editor of course)... hitting those four missing bytes with the Poly Stepsequencer will be very rare... length would have to be larger than 60 steps... and those steps would have to have six keys pressed at the same time to happen (five or lover should not be a problem), and only the velocity of those four last steps is the problem... and only happening on Layer B... it's obvious that it's a very rare bug to run into.
Besides, I suppose that you can edit these four bytes via NRPN correctly (have not tried this yet, but I see no reason it should not work as it has nothing to do with the SysEx data)... so if you REALLY needed those to be right when editing from an editor, you could simply store the edit buffer from the REV2 frontpanel instead, saving it to a location, and it should be fine I guess...
You could also correct the bug with an editor actually... if you have the right data for the four bytes in the structure inside your editors edit buffer, just send this with the flaw to the REV2, and after this, send out four NRPNs with the right data for those four missing bytes... problem solved.... the only real problem is when you request a program... you'd have to edit those four missing bytes on every dump yourself (logically).
But all in all... yes... a small bug that DSI obviously chose not to bother fixing because it's too complicated... fair enough.