the intent in ReiserFS is that ID3, EXIF tags and the like would move into sub-files.
The problem with this is the concept of "files with subfiles" is not a thing outside of ReiserFS. Sure, if people used ReiserFS, they'd have this feature, but how would you transport such files between machines? You'd have to serialize them somehow: this is exactly what ZIP is.
(Remember HFS resource forks? Me neither. They suffered from exactly the same issue: ambiguous transport semantics.)
Optimizations around such things are exactly that – optimizations – and should not affect the semantics of the objects involved. The proper way to approach this is to decouple data storage from indexing from file semantics. Hence a better approach would be to permit access to contents of ZIPs using FUSE (on Linux) or what-have-you, and index the contents in a database like Spotlight (on OS X).
If a file is a .zip, then it's a .zip and it can use zip tools. If it's not a .zip, it can use the file's own tools (like if it's some kind of music archive). But not both.
Ignoring that OOXML (.docx etc.) already takes this approach (zipped XML files), the problem of allowing multiple different programs to access the same type of file is a minor enhancement to the OS. (I'm pretty sure you already can configure Windows to allow .docx to "Open With..." a ZIP program.) Supporting files-which-are-also-folders requires breaking quite a few more assumptions in OSes.
The problem with this is the concept of "files with subfiles" is not a thing outside of ReiserFS. Sure, if people used ReiserFS, they'd have this feature, but how would you transport such files between machines? You'd have to serialize them somehow: this is exactly what ZIP is.
(Remember HFS resource forks? Me neither. They suffered from exactly the same issue: ambiguous transport semantics.)
Optimizations around such things are exactly that – optimizations – and should not affect the semantics of the objects involved. The proper way to approach this is to decouple data storage from indexing from file semantics. Hence a better approach would be to permit access to contents of ZIPs using FUSE (on Linux) or what-have-you, and index the contents in a database like Spotlight (on OS X).
If a file is a .zip, then it's a .zip and it can use zip tools. If it's not a .zip, it can use the file's own tools (like if it's some kind of music archive). But not both.
Ignoring that OOXML (.docx etc.) already takes this approach (zipped XML files), the problem of allowing multiple different programs to access the same type of file is a minor enhancement to the OS. (I'm pretty sure you already can configure Windows to allow .docx to "Open With..." a ZIP program.) Supporting files-which-are-also-folders requires breaking quite a few more assumptions in OSes.