Unexpected mutation of collection.find and documents

I've recently noticed that the package mutates queries passed to collection `find` methods, as well as adds an extra `esSearchResult` field to documents (even those that aren't remotely involved with any search index at all). This is actually pretty insidious, since the same queries that work client side would silently fail on the server, where documents don't have this extra `esSearchResult` property attached. I'd imagine this could also cause problems wherever any document's keys are enumerated, or wherever the document's `keys.length` is concerned. 

Correct me if I'm wrong, but it looks like the purpose of adding these extra fields is to differentiate the results of the search from existing documents/collections. If that is the case, wouldn't it save some headaches to just separate the search results completely from the existing documents?

So, the idea is to create a local collection specifically for search results, and publish directly to this collection (as opposed to meddling with existing collections). This makes it a lot less likely that searched documents will clash with existing code somehow, and also saves us some awkward workarounds (like setting up an extra `esFind` or adding hidden properties).

I haven't thoroughly tested this approach, so there may be some drawbacks I'm overlooking. (Off the top of my head, I guess you could argue that this potentially causes duplicate documents to be published, but then again, the local collection can also serve as a cache for past searches, thus improving performance.) I've only briefly tried it with the `mongo-db` search, which appears to work well. The `minimongo` search doesn't require pub/subs at all, if I'm not mistaken, so that should work as well.

Anyway, this is just an idea to consider, and hopefully to build upon. 
Cheers :)