In essence, yes, you understood me. "GTDOS" is about tackling the problem top-down (interacting with the GTD flow meta-data, tags) and bottom-up (file and directory management, low-level UI behaviour, managing the meta data and tags).
There was some talk not too long ago about MS coming up with a database file system. That would suggest some approaches to tackling the bottom-up data management, assuming the database is flexible enough to be marked up and isn't yet-another-static-format file system, where you're stuck working within the statically defined attributes+properties legacy.
Regarding windows program or web-based, change "or" to "and". Web-based sucks when you're offline or working over slow connections; windows programs suck when you're not on a windows machine. That said, under GTD everything is managed according to projects, reference material and next actions. Over a slow link my mini-app talks GTD meta-data and I pick'n'choose which docs I need if I don't already have them sync'd locally.
Aside: As a techie/coder, this is why I love XML-formatted data. It separates form from function. Sure it gets big in plain-text mode, but most compression algorithms (good old zip, jar or bz2) work wonders because of the inherent redundancy; gotta love information theory. Every language, including Java, can handle compressed and encrypted data, and has some sort of mechanism for parsing and processing XML. MS and others finally import and export XML formats; even graphics can be stored and manipulated via SVG.
By changing the file meta-data, a dynamic file system could move around where links to the file show up - which set of "folders" it shows up in, how next actions and associated calendar entries are created and managed...
...add a property called "GPS Coordinates" and your shopping list and pictures of the vegetables you are supposed to buy will be pulled from @Errands and Reference and sent to your cell/blackberry as you approach the grocery store on your drive home from work.