thankfully, unless actively you’re seeing the distro time on the [timing] screen change to unexpected values, this isn’t related. the arp/pattern issue requires a super-specific set of actions to invoke – you need to engage a pattern recorder, start pressing buttons, engage arps, keep pressing buttons. one of the goals for the next month is to allow arps + patterns on the same bank to play at the same time and feed each other, but for now it’s best to treat them as separate ways of handling time.
as you shared, this issue is near-impossible to reproduce reliably. patterns are a hybrid of the older metro system (free) and the new clock system (distro) – expressive hand-played patterns seem to flow reliably in both modes, but this is probably why a rigid pattern like snake would occasionally get tripped up. the individual events in a distro pattern (which is what snake patterns default to) aren’t fundamentally quantized to anything – they are driven by the metro system and the only truly clock-aware event is a reset which re-starts the pattern playback after x bars. so my best guess is that these two separate timing methods are just getting out of sync with each other and that’s where the hiccup occurs.
tl;dr: i’d suggest pulling out the WIFI nub and seeing if that helps.
i was also doing some thinking about what you had proposed and i think that the snake functions actually would be better as arp modes. arps are fundamentally quantized events – they don’t record organic time, they just queue their events and then this queue is systematically walked through with each global clock beat. since snake modes are all fundamentally queued events, i’m realizing it was actually a weird decision for me to have married these to patterns – they ought to have always been arp modes 
