The resource fork idea was OK, but it suffered from a implementation optimized for a floppy disk. Writes were deferred as long as possible, and if anything went wrong, the whole data structure was corrupted.

"Text Edit is not a text editor, and the resource fork is not a database" - early Apple publication. Both could have been. Programs tend to need little databases, for preferences and such, and the resource fork was way ahead of doing everything with a text file. But the implementation was never toughened up to database standards after the Macintosh got a hard drive and more memory. And Text Edit was limited to 32K for a long time.

Meanwhile, Unix struggled along with text files for everything. And lock files for the text files. And daemons to remove dead lock files. And a lack of file locking. And a lack of interprocess communication. Eventually the Unix/Linux world got that all fixed, but way too late.

This could be handled by convention of treating directories as though they were a single structured "file" under certain circumstances. There is precedent in the form of Application Directories from NeXT, RiscOS, and ROX Desktop. Modern MS Office files are also basically just a zipped up directory of files and metadata.