Well, yes, the widget itself is actually provided by libbaloowidgets4 I suppose, sorry. This in turn uses kfilemetadata to get the metadata.
But that doesn’t change the fact that it is unrelated to baloo-file, the indexer.
You cannot uninstall kfilemetadata and libbaloowidgets4 anyway, as they are required by dolphin.
But again (a last time
), this was exactly the same with Nepomuk. NepomukV1 has that widget in libkde4 and used strigi for indexing and metadata extraction. NepomukV2 (which Dolphin uses in 4.10?, 4.11 and 4.12) had it in nepomuk-widgets and the metadata extractors, i.e. what is now kfilemetadata4, has been in nepomuk-core.
So why is it suddenly much worse with baloo? 
In fact the packaging is much more fine-grained now, so it is actually possible to uninstall the indexers without losing any other functionality.
Regarding your other, all very valid points; this emphasises the point I was making, we all have diverse uses. Personally I too would want meta data related to the actual file I had (knowingly) attached it to, and yes, I would expect it to remain if the file was moved, but not so on copy.
Is it retained on copy as well? I don’t think so.
I just added a comment to a file, copied it with dolphin, and the copy DID NOT have any comment.
Anyway, that would be no different to ID3 tags f.e. then. Do you complain that when you copy an MP3 file, the copy contains the tags you added, too?
Btw, beagle did store everything in extended attributes already, and I think tracker does as well, but I’m not sure.
One other thing with baloo at the moment is simply, what is stored where, by what, when, and for what purpose? Questions which should be addressed to the developers of course. At the moment, as far as I had established there is the xapian database, an sqlite database, and the extended file attributes…
As I said, I don’t know all the details, but AFAIK there is only one database, the one in ~/.local/share/baloo/. (well, actually separate ones for files, emails, contacts, notes, …)
This is a xapian database. This is the search index, which has to be central of course, otherwise the whole purpose of an indexer is void.
I see one sqlite file in there as well, ~/.local/share/baloo/file/fileMap.sqlite3, there may be good reasons why this is there. By looking into this, it only seems to be used to connect the internal numeric id with the actual URL of the file.
Whereas Nepomuk used soprano for that, and either redland, sesame, or virtuoso as backend.
There will be a lot of people who chose to use baloo, of that I’m certain, I for one, won’t be amongst them. As for deep integration with KDE, we’ll have to wait and see what happens. With nepomuk one could easily and reliably disable the ‘semantic desktop’, file indexing, and mail indexing. I’m sorry, but I don’t see this with baloo.
What is it that you don’t see?
Again, it can be disabled exactly the same, even in (nearly) the same config files. The option to disable baloo-file was missing in the GUI in 4.13.0, but is there now.
If disabling it doesn’t have effect that’s another story, I don’t know whether that’s the case.
There is no option in the configuration module any more to disable mail (PIM) indexing, true. But AFAIK that should be doable by just removing the “Akonadi Baloo Indexing Agent” in Akonadi’s settings. TBH, I never disabled the Nepomuk PIM indexing anyway. I rather disabled indexing for all my mail folders, as I said this can be configured on a per-folder basis in KMail.
And there is no server process any more, so there is no need to disable the server process.
The only difference is, that baloo’s libraries can access the database directly now, without the need of a separate server process. But I would rather regard that as advantage.