Right, with you now. We absorbed Mopidy-Local-Sqlite into Mopidy-Local and I’m still not that familiar with how all of it works but I had a dig and found https://github.com/mopidy/mopidy-local/blob/master/mopidy_local/storage.py#L84
Which stems from the fact the database stores image info within the album table. So no album means no image. This is probably because in older versions of Mopidy, only album artwork was supported; get_images didn’t exist and the only images available were those found within the track.album data model. We removed that restriction to support images for any URI (playlists, artists, searches) and there’s already a thought-out plan on how that could be added to Mopidy-Local https://github.com/mopidy/mopidy-local/issues/13. The schema alterations proposed there to decouple images and albums would also be needed to solve your problem. I think the age of the issue might have something to do with the lack of demand for the enhancement, combined with the fact Mopidy-Local does not have a maintainer. And perhaps also because some frontends take over the duties of gathering artwork and will try and find it online.
So the only workaround for now is to set a dummy album tag, like you say.
Out of interest, what sort of tracks are these with embedded artwork that isn’t album artwork? Singles?
Edit: and just to be clear, if you are interested in fixing this issue yourself, please do. Although there’s currently no maintainer, we can potentially still review and merge some PRs, it just might take a while.