Why is thread safety a concern when sharing OMElement trees across threads?

Axiom's default (LLOM) implementation isn't synchronized for concurrent mutation, and crucially, navigation itself can be a mutating operation under deferred building - calling something like getNextOMSibling() on an unbuilt part of the tree causes the builder to pull more events and modify internal linked-list state as a side effect of what looks, from the outside, like a simple read.

If two threads navigate overlapping, not-yet-built parts of the same tree concurrently, they can race on that internal state - one thread's in-progress build of a node can be interleaved with another thread's attempt to read or extend the same structure, producing a corrupted tree, missing nodes, or an outright exception, none of which are reliably reproducible since the outcome depends on timing.

The safest patterns for concurrent access are: fully build the tree (build()) on a single thread before sharing it, so no further parser interaction is needed and subsequent reads are genuinely read-only; give each thread its own independently-parsed or independently-cloned tree instead of sharing one; or explicitly synchronize access to a shared, still-partially-built tree if sharing genuinely can't be avoided.

This is a subtler hazard than most thread-safety bugs, precisely because "just reading" an Axiom tree isn't actually guaranteed to be a pure read if the tree isn't fully built yet - a detail that's easy to overlook when porting code from a fully-eager model like DOM, where post-parse trees genuinely are safe to read concurrently.