Tight integration of archive manager functionality

I have for some time now been perplexed as to the reasoning behind the separation of file management and archive management. After all, to the casual the end-user an archive is little more than a compressed file or folder. Surely then it makes sense to manage files, directories and archives within the file manager interface!

I thus propose that Marlin should incorporate archive manager functionalities, and obfuscate as much as is practical the distinction between a file, directory and an archive. Obviously there should be visual cues (such a icons, emblems and chrome/UI colourations) to signify the presence of an archive and perhaps identify the algorithm. However, where the end-user is concerned, managing (editing, deleting, copying and moving) an archive and its constituent files should be indistinguishable from managing raw files and directories.

For example:

1. An archive (example.7z) containing a single file (example.odf), should appear as a .odf file with an emblem signifying that it has been archived and (if applicable) compressed. This emblem should indicate the archival algorithm used. When the end-user double-clicks this icon, the archived file (example.odf) is extracted to a temporary hidden directory (.~example.7z) in its parent directory and the default action (editing with LibreOffice) applied. Once the file has been edited and saved the modified file is re-archived and the temporary directory deleted.

2. An archive (example.zip) containing multiple files, should appear as a standard directory (perhaps with a different coloured directory icon) with an emblem signifying that it has been archived and (if applicable) compressed. Again, this emblem should indicate the archival algorithm used. When the end-user double clicks this icon, the archive should be opened within the file manager as if it were an ordinary directory. Again, a temporary hidden directory (.~example.zip) should be created in the parent directory for the purpose of file management purposes. It may also be of utility to apply some form of UI colouration (location-bar, background, etc...) to make it clear to the end-user that they are browsing an archive.

Furthermore, when the end-user requests compression of a given file or directory, Marlin should suggest the optimal compression algorithm based on context (i.e. 7z for text files, etc...). If this can be reasonably achieved (i.e. without delay) via some form of benchmarking to determine the ideal compression algorithm on-the-fly, that would be excellent. However, I suspect that such an approach would be time consuming and CPU intensive, and so context (i.e. what type of file(s) is being archived) should be used to determine the optimal compression algorithm based on what is generally known.