NIP-10 is an over optimization from my point of view. Where my base case is that I store events in a graph and know exactly which thread any note belongs to by it's direct parent. And I know every descendent from the root.
Otherwise, any client that doesn't use NIP-10 will break your app. And it's too easy to not use NIP-10 because it's not strictly necessary from a user's point of view, and a part of your life will be dedicated spent policing other clients' NIP-10 compliance.
I don’t think it’s an over optimization. You would need to make N relay subscriptions sequentially (N being the number of events in the thread) instead of one relay subscription in the worst case to even be able to populate your event graph in the first place. It’s highly inefficient, but also as you described it, probably necessary because it’s easy to not conform to NIP-10 properly.
It would require clients to use another filter field, but the relay I'm working on will be capable of serving an entire thread with 1 subscription (or potentially a DVM). It may be useful enough for some clients to adopt it.
In that scheme, you can return a whole thread from the root note or from any branch whether clients use NIP-10 or not. And serve new notes that appear in thread over time.
