A minor semi-bug and solution I just worked out - posting here mostly so it might come up in a search if someone else has the same issue (or, probably even more likely, I have the same issue again and forgot how I solved it
"Random" (and "Square", to some degree) can be seen a little bit differently from the other wave types in how "Rate" works. Sine, Saw, etc, are continuously updating (at a rate determined by the Update Frequency in Peer LFO - default is 1 tick).
Because "Random" is a constant, however, it only updates once per Rate. Update Frequency (as far as I can tell) has no effect.
When using "slower" rates, it's possible for "Random" to become quite audibly detached from actual song measures. For instance, a Rate of 32.0 (once every two bars) could end up with new positions on the 12th Row of a Pattern (and then again on the 44th Row, and the 74th, and so on) - this could be interesting for polyrhythms, of course, but generally one would prefer each new position to come at the 1st (or 0th, to be technically precise I suppose) Row (and 32/64 or 33/65 Rows, and so on).
Basically, the way Peer LFO decides when to update "Random" is to count upwards from 0, with a modulus of whatever the "Rate" is. Once it hits "0" again, it gets a new "Random" value. However, critically, Peer LFO never forgets what number it's on, and that number is free-floating, not tied to the position within the overall track. This means that if Peer LFO is set to Heed Transport and you stop playback at, say, the 20th Row of a Pattern, then go back and play the song from the beginning, Peer LFO will start counting at "21", which will result in the "desynced" behavior I described above - updating 12 Rows off the start of a new Pattern.
(If Peer LFO is not
set to Heed Transport, then where exactly it will start from is basically random for human purposes, since in this case it's counting constantly behind the scenes)
In order to force a proper alignment of Random values, you must set Peer LFO's manual phase to 100% at the start of a track. This, of course, only works when playback begins at the start.
Note: Setting it to 0% can also work, but if you're looping back to the beginning, this will result in occasional minor glitches, where Peer LFO decides on a new value, starts heading towards it, song loops, Peer LFO gets zeroed, decides on another new value, and heads towards that one instead. Setting it to 100% ensures that Peer LFO won't change its mind out-of-turn.
(the upside of setting it to 0%, however, is that then you can just say "zeroing the value", which flows off the tongue so much more easily, doesn't it?
Obviously, this issue also affects the other waveforms too, in that the peaks will occur at different parts in the song. However, because Random updates less frequently than other waveforms, it can create more drastically-improper results. For instance, when assigning Peer LFO to the Note value, with manual note offs in the slaved machine's pattern, you may be left with too-long silences and too-short notes, since the Note event only fires once Peer LFO changes position.