During some debugging to figure out what was wrong with something in our code, I discovered that the prematch equality checking was returning true when it should be false. For example, if you’re doing a find and replace tool and you have multiple results on a line and it starts at pos 0 for the locals in the decoration set, it matches the first result, then it proceeds to compare that first result to subsequent ones, and instead of matching position or by reference, it just matches by markup and deep compare attrs/spec. As a result it thinks everything is equal and it proceeds but never adds the supposedly equal text nodeview, which i imagine in the minds of most people would be wrong.
This equality behavior can be defeated by adding any field to an inline decoration that is unequal the the other inline decoration. It then fails to pass the equality check. Maybe I missed it, but, I feel like the API and docs do not explain this nuanced behavior.