> I'm not immediately seeing how that would be useful in a file context, where generally you want to look up a specific blob of data (aka a file).

I would really enjoy a filesystem that's a loose tag-based hierarchy rather than a strict single folder tree.

In SQL terms, something like:

   create table files (
       file_id bigint primary key
     , file_name text
   )

   create table tags (
       tag_id bigint primary key
     , tag_name text not null
     , parent_tag bigint null
     )

   create table file_tags (
       file_id bigint
     , tag_id bigint
   )

So tags are organized in hierarchies, but there can be multiple parallel hierarchies, and a file can belong simultaneously to multiple hierarchies. Say one is a flat list of tags by user, another is a flat list of tags by apps, and another represents replication or backup strategies, plus the usual directory organization.

(I'm not sure if a file should be allowed to belong to multiple tags within the same hierarchy; my gut says no.)

Let's say that as a convention we separate the root tag in each hierarchy with a colon, and other tags with a slash. Your file 'cool_code.py' may be found under the tags 'storage:sda', 'users:roenxi', 'apps:pycharm', 'pycharm:projects/cool_app/src/utils', and 'rclone:gdrive/roenxi@gmail.com/202201'.