Partly incorrect, a single m-TAG file can either describe a single media file or a collection of multiple media files, comparable to a cue sheet. and it is not intended as a backup but as the primary container for meta data. In other words, media files are treated as if they are read-only and meta data will never be written to actual media files unless explicitly instructed by the user.
Furthermore, it allows the use of metadata for media formats which either have limited or no support for mediadata themselves. For instance, a m-TAG file can describe a streaming source and allows to store meta data not contained within the stream. In effect, it forms a totally separate layer, allowing for much greater flexibility in describing media regardless of the capability to store said meta data within the media file itself.
Currently MP3tag seems to support the reading of a cue sheet with this difference that it then proceeds to read in the media files referenced by the cue sheet. Any changed value however seems to be directly written to the media files and not to the cue sheet (due to the limitations of cue sheets)
What I would like to see is that MP3tag reads the m-TAG files as if they were media files, without also loading in the referenced media files (as the primary entrance is the m-TAG file itself) and any changes made written back to the m-TAG file(s).
I am aware of the fact that this could possibly lead to confusion if both the m-TAG file(s) and media files are located in the same folder (which is not a requirement for m-TAG files as they can be located in a totally separate location) if the user does not also have a column showing the actual filenames, but I trust that if someone uses m-TAG they will be aware of this fact and capable of using MP3tag's filter option to limit the view to the entries provided by the m-TAG file(s)