Desyncs

This is a list of things that can cause a desync in 1.32 and later. These are not caused by HiveWE, but having a list is handy.

General

Code in GetLocalPlayer() blocks will cause desyncs if it makes changes that should have happened on both player clients at the same time. The following will cause a desync because the unit is deleted on only one client.

if (GetTriggeringPlayer() == GetLocalPlayer) then
    KillUnit(GetTriggeringUnit())
endif

But the following will not because a UI frame being visible or not is not something that needs to be synchronised between players.

if (GetTriggeringPlayer() == GetLocalPlayer) then
    HideFrame(SomeFrameID)
endif

Using GetLocalZ() for things that need to be synced between clients (e.g. killing a unit) will cause desyncs as there are height differences between Classic and Reforged graphics.
The CreepCampPathingCellDistance gameplay constant will desync if players don't restart their game before playing your map.
Frames are cached between maps, so if you create a frame before loading your .toc it can create the frame for some people but not others.
(Unconfirmed) local unitID = GetHandleId(unit) is playing with fire, as this leads to desyncs in Lua (it definitely has different values between players, this then may have a cascading effect on what the GC collects)
GetRandomInt/Real/math.random in a GetLocalPlayer() block will desync because the random generation is no longer in sync between players.
Calling ForForce or ForGroup inside a GetLocalPlayer() block guarantees desync, Select group for player GUI action is such example

Creating objects outside of the main function in Lua is prone to desyncs. To lazily solve this I moved TSTL's module creation inside of the main function.
Using StartTimerBJ and bj_lastStartedTimer will cause desyncs. This also means that the GUI Countdown Timer - Start Timer will desync. Use TimerStart() in a custom script block instead.
Iterating produces pairs but the order of iteration is not guaranteed so can differ per player.