This post of Emiliano make me realize that I've not explained what's my interest in such a feature. Here are few explanations.
My library is organised exclusively with thematic collections, rather than with thematic tags (which are limited in number, because of the only nine colors). I prefer to use tags to adding informations for myself, for which colors add a real value. For instance: #toread (in blue), #tobuy (in red), #tosummarize (in yellow), and also to gather references for a specific use like [PhDbibliography] (in green).
That's why, in order to write a chapter of my PhD thesis with LaTeX, I need to export in Bibtex my references tagged in green, but not all, only the ones stored in some specific collections. In doing so, I use a saved-search. Everything works well manually. But it would be much better if the export was fully automatic, like BetterBibtex offers for collections.

This is of interest to me as well. I use tags and smart searches to create local groups, so being able to export these groups automatically via BBT is very useful.

EDIT: clarified that it's the auto-export I'm talking about.

I use colored tags and number keyboard shortcuts to add items to saved search collections. Saved searches are nicely kept updated with zotero 4 and BBT. It's the quickest, best workflow I've found so far. I reverted back to Zotero 4 when I saw 5 didn't allow for auto-exporting saved searches.

I have to add that Zotero didn't break anything in the move from 4 to 5, it's just that detecting that a search was being exported used *very* invasive monkey-patching of Z4. I want to really scale back the complexity of monkey patching BBT does, certainly now that the async architecture Z5 raises the risk of hard-to-debug race conditions.

(edit: rave conditions are notoriously hard to set down, but I meant race conditions of course)

Technically, I monkey-patch Zotero.Translate.Export.prototype.translate to inspect what is being exported, and put it in my auto-export administration if I can find something that I can use to reproduce the export.

For a library export, I can remember ._export.type (which will be 'library') and ._export.id, (the library ID); if a reference changes, I can check whether that library was affected.

For collections, I can remember ._export.type (which will be 'collection') and ._export.collection.id, (the collection ID); if a reference changes, I can check whether that collection was affected.

For searches being exported, only the list of items that are in that search *at that time* are available. To test even *whether* a search is being exported, I'd have to run all searches you have.
The way I used previously was to monkey-patch the right-click-to-export on the search (at which stage I have the search ID), replace data into the export request being set up with non-compatible data, assume that that data will travel all the way to the Zotero.Translate.Export.prototype.translate call unscathed without messing up anything in the interim in Zotero, and then undoing that just before calling the original. Or something to that effect at least, it's been a while, but the code wasn't pretty. I don't mind monkey-patching but I like it to be localized so it's less likely to cause interference, and this string of monkey-patches that modified the internal structures that Zotero expected assuming I could undo those changes just in time... what with async ruling the land now... no.

To do this cleanly, all I'd required is ._export.type be set to something like 'search' and the search ID to be present (e.g. on ._export.id or on ._export.search.id), or even just the presence of ._export.search (with an ID), and I'd be golden. I assume Zotero is not currently doing this because it's not necessary for regular Zotero usage; searches are (relatively) expensive, and if you right-click the search to export it, it is first displayed, so the search has just been executed, and the results can just be used for the export, so Zotero hands that list to the exporter. There's no need to pass the search to the exporter as you would never have to re-do the search in Zotero in that path.

Note that even if a ._export.search were added, auto-exports for search is still relatively expensive. When a reference changes, I have to run the auto-exported searches to see if the changed reference is in the result set, so you wouldn't want to have a lot of these with complex conditions set up for auto-export.

As far as I know, nothing has changed.

nothing has changed.

Will this be possible in Z7?

If I understand correctly this would be a feature for the better bibtex plugin rather than zotero itself is that correct? Unless you sort of "monkeypatched" it which seems unlikely.

How do we encourage the makers of better bibtex to implement this? What do they need to make it happen?