RList's merge operation is O(n)

The choice of 'a list as the exposed data type imposes slow O(n) patch application.
It'd be nice to have another module using another list-like data type (something similar to Okasaki's random access lists or such) which would allow for more efficient merging. Getting an 'a list back (which should be a rare event) would likely be O(n log n), but any operation (but taking the head) on the list would be O(n), so that's OK -- plus there wouldn't be hidden costs.

Alternatively, it could make sense not to update the current value eagerly, and to apply the patches lazily on request of the value (e.g. Tyxml_js works directly with the patch event, so there's no need to compute the actual list value in that case).

Start by reading the current RList implementation and the patch-application path; the issue does not name files or tests. Review the Tyxml_js example linked in the issue for the lazy-consumption alternative. Done would require an agreed design and implementation that improves merge costs without imposing the current eager-list behavior.