[Spliff]

It just occurs to me that the full core code, in other context, is already there, in order to implement at least an "ordered" (=in tree order), partial or total, but complete (=no "filter orphans" anymore), flat-list flag filter within the Data Explorer (=tree pane):

In tree, source item is selected = total filter; some other (parent of a sub-structure) item is selected = partial filter, same code.

File - Export - Item attribs to CSV - Attributes to export: Flag, IndentLevel, ItemTitle - targetfilename (Export child items recursive yes) path:\name.csv - Finish

gives: tree-ordered flat list in the form
"Item Title",FlagInCase,IndentLevel (or then "ItemTitle",,IndentLevel")

Ok, if it was in the form
IndentLevel,Flag,Item Title
you would even avoid the quotes around the item titles, but that's a minor flaw, fact is:

The above is in tree order

Flag info is there in order to format/color/etc the entry accordingly

(Even indent level info would be there in order to replicate the tree,
then code (outside sql: loop: "preserve if any child (=while indentlevel > current one) is to be preserved") could select the necessary intermediate items in order to replicate the tree form, but that is NOT necessary, so indent level info is not even needed, leave it out, do just Flag,ItemTitle above, which brings "Item Title",Flag)

Then just delete the array rows to be hidden (flag name/number not in the to-be-preserved-list), and put the remaining output into the Data Explorer, just as otherwise you would write it into the .csv file.

And since then, the Data Explorer content would be a flat (but formatted) list, without any indentation, even the caption would not to be changed, since the user immediately sees, from the content's "form" (=visual aspect), they are in "tree preserving flat list mode". ;-)


(I don't know about the possible (tree, not content) editing functionality of the current (sic!) flag filter, didn't dare try (item moves?), so admittedly, if you wanted to preserve those (if there are any) for the flat-list, that would complicate things, considerably in case. But for me it would be perfectly acceptable if the flat list would just SHOW the filtered tree correctly, perhaps with navigation = showing (and possibly editing) the respective content (as it is now, but even content editing in that "view" would not be absolutely necessary, ditto for item renames, not really necessary either)... but a Return (Enter) within the tree would LEAVE the flat view, and show the regular view, with the item from which the Return was done, being selected.)