Minecraft 1.4.4, Minecraft 1.4.5, Minecraft 1.4.6, Minecraft 1.4.7, Snapshot 13w05b, Minecraft 1.5.1, Minecraft 1.5.2, Snapshot 13w18b, Snapshot 13w18c, Snapshot 13w23b, Snapshot 13w24a, Minecraft 1.6.2, Minecraft 1.6.4, Minecraft 13w42a, Minecraft 13w42b, Minecraft 13w43a, Minecraft 1.7, Minecraft 1.7.1, Minecraft 1.7.2, Minecraft 13w48a, Minecraft 13w48b, Minecraft 13w49a, Minecraft 1.7.3, Minecraft 1.7.4, Minecraft 14w02c, Minecraft 14w04b, Minecraft 14w06b, Minecraft 1.7.5, Minecraft 14w11b, Minecraft 14w18a, Minecraft 14w18b, Minecraft 14w25b, Minecraft 14w26c, Minecraft 1.7.10, Minecraft 14w27b, Minecraft 14w28a, Minecraft 14w32d, Minecraft 1.8-pre1, Minecraft 1.8-pre3, Minecraft 1.8, Minecraft 1.8.1, Minecraft 1.8.2-pre6, Minecraft 1.8.2, Minecraft 1.8.3, Minecraft 1.8.4, Minecraft 1.8.7, Minecraft 1.8.8, Minecraft 15w31c, Minecraft 15w33b, Minecraft 15w35d, Minecraft 15w35e, Minecraft 15w36d, Minecraft 15w41b
Boats have synced badly for a long time now.
To begin with, each boat has a flag telling whether the local player is controlling the boat. This is only updated upon entering, but not exiting the boat. Until the boat is reloaded, it will always think the local player is controlling it. The server sends packets of the form [player attached to boat] upon entering and [player attached to null] upon exiting. It seems the code interpreting the packets expects [something that is not the player attached to boat] instead of [player attached to null].
That flag is used by the client to pretend to have complete control over the boat. It stops responding to position updates sent by the server (1.8 changes this slightly). The updates set some internal variables, but those are never used to actually update the boat's position. Due to this lack of updates, the client's position quickly diverges from the server's. This leads to boats hitting things and possibly breaking in what appears to be open water. In extreme cases you could (before 1.8) run off of the edge of the world on the client, because the position was off by all of the render distance.
The client runs full server code on boats it believes it's controlling. This includes breaking lily pads and snow layers in the boat's way. This is another source of desync because it updates the local view of the world without the server's consent. In the lily pad test case you can see two trails of broken lily pads, one of them due to a hallucinating client (not visible on the attached screenshot, which is of an older version).
Since 1.8, boats do respond to forced teleports, which generally occur every 20 seconds or so. They will instantly jerk to the reported position and set their velocity to zero. Makes for a very jerky ride that actually creates some desync as I'll detail in a moment.
A good test case is/used to be a superflat world with preset "3;minecraft:bedrock,2*minecraft:water,minecraft:waterlily;24;oceanmonument,biome_1". Place a boat and gently move around (so that the boat breaks lily pads, not the other way around). The desync should soon become apparent when the server breaks lily pads that don't appear to be near you. If you manage to break the boat, the resulting planks and sticks will drop where the boat really was, whereas your character remains where the client thinks it was. 1.8 still wreaks havoc even though it kind of fixes itself periodically.
Yet another issue is the mishmash of client and server control that was the intended result. The client predicts the boat's movement by reacting instantly when you press a key or move your mouse. You can't conflate the position reported by the server a round trip ago with the current predicted position. If you do, a few moments after accelerating you will jerk backward. After stopping, you'll jerk forward. After turning 90 degrees, you'll jerk sideways. That's what 1.8 does periodically now.
So many things are broken. Every attempted fix only makes things more convoluted without truly fixing anything. I stand by my suggestion (which I left in the comments over half a year ago, before I got to own this report) to leave everything to the server. My point that you don't know what you're doing has only become more solid. So keep it simple. Boats react very slowly anyway, so a little bit of network latency is hardly noticeable. Horses are much more sensitive, yet the client doesn't predict them.