Even the ability to call out to a small program with the file path to return a true or false to importing would be great (it could even by a python, ruby, bash command or scripting language, anything like that) would allow you to do this. The ability doesn't have to be within MC.
Sorry, but that is just getting silly. MC would still have to know to call out to an external program, and would have to accept the result coming back. I don't work for JRiver, but if I did, I would never consider that. Particularly to support third party functionality, and a kludge at that.
The wildcard idea isn't a bad one, but have you noticed how MC only allows you to select existing folders for import, and validates each folder as you enter it? Of course, you can add a folder through the Browse functionality, but you can still only select an existing folder, even if you just created it. A change to using wildcards would require big internal changes.
If you wish to support multiple iDevices and Apple technology applications, why don't you just convert your FLAC files to ALAC? MC plays both, and you could potentially simplify your whole music management process. I just had a quick read on the Pure Music Bookmark solution. Ahhh!!!
But if you really must maintain iTunes for iDevices, and don't want to convert your FLACs to ALACs (which I believe would be a lossless conversion), and therefore want to keep using the Pure Music solution,
just let MC import all those extra files, and then exclude them from all View and Smartlist definitions. They will be there, but you won't see them in MC.
-[Filename (path)]="data_folder"
-[Filename (path)]="Pure Music Bookmarks"
In English, those expressions say 'The path does not contain "data_folder"', for example. Including both those in all your View and Smartlist definitions will hide all files stored in those folders and any subfolders. It would be a bit of work to add those to all View and Smartlists, but not too onerous.