On the 'Why hasn't it been done this way before?" note, it has- NeXT pretty much brought the concept of extensible docks to bear, as someone one had to point out to me on AmiOpen. (In that case, I was arguing in favor of vectorized/scalable displays; apparently NeXT had more prominent user control over scaling of 'dockapps,' or so was said. I've never seen screenshots, and I gathered GNUStep/WindowMaker was taking credit for invention of active content in docks... not really sure, even today.) This new system gives a lot more control over presentation of NeXT-ish docks, though, while most other UIs have followed the Lisa / CDE? / Windows model of limited functionality.
As a UI nut, I'd say there's a conceptual difference between the two approaches; an extensible dock is an area of reserved screen real-estate where overlap doesn't occur. (Those who know me know I'm not a big fan of overlap, especially as relates to the conventional 'cluttered desk' metaphor of interface presentation.
) A special-purpose dock is 'just' a funny-shaped window made such to get around the limitations of the windowed environment; it's the UI designer's way of saying, "Well, the interface to *my* product- the OS/Workbench/IE- deserves to be special, but you peonic third-parties only get regular windows, or a little tray on the right, or reimplement your own d*mn solution." I've got nothing against controls reserved to the OS, of course, *if* non-OS software can be allowed to achieve the same level of usability/consistency. (Hey, modern systems have this problem licked! They just make sure *nothing* is usable or consistent! :-D)
...An area of reserved screen real-estate that behaves differently from all other areas (regular windows) can't help but be 'special,' of course... so looked at in that light, the OS X dock does almost as good a job as the NeXT dock, if having failings on aesthetic/efficiency (screen real-estate) grounds; I haven't used it much, but IIRC they've chucked in a sort of "Harvard architecture" enforcement between the left and right sides, which is probably good UI except for the inflexibility in choosing other arrangements (documents organized next to the creating application, say). AmiDock has the potential to do it all, including NeXT/Apple-style persistence (with the automatic adding feature)... with the more flexibility than most previous implementations.
To shoot down one example- OS/2 certainly had good ergonomics with the WarpCenter, but zip for extensibility. Usually, apps didn't bother seeking the same level of presentation (mostly a sign of the times; today, every app, no matter how trivial, seems to demand its own odd-shaped window or 'remote control' dock/tray app); I think I remember one ICQ client that claimed to change its desktop icon based on status, but 1. I never got that to work, and 2. I have no idea if it was a cheap hack or a relatively sane API call.
If I had to call hiatus on AmiDock for anything, it might be for perpetuating the 'everything a [file|object], some objects dockies' arrangement, rather than shooting straight towards 'everything a docky, some dockies can hold/present files.' I have no idea what the code looks like, so it's probably quite feasible to switch over to that approach/probably arranged internally that way, anyway.
I should also note that, once we all have videowalls (literally; I give it 20 years or so, maybe 50 before we can actually put up displays *exactly* like wallpaper- insert horrific Windows Powered 'Blue Room' visions here), user-positioned windows do become less of an issue... in tradeoff, if you think 'skins' and aesthetic candy are a problem *now*... Well, hopefully we'll see more stuff in the vein of e-mail fishtanks (props to DALiworld) and network-monitoring cricket chirps.
---
[Edited after I posted the main glob with my browser on the brink of crashing, and refreshed my understanding of Commodities.]
As to commodities- I was wondering about that in the back of my mind, myself. If I understand things properly, commodities.library is simply about allowing background I/O - though I'm not quite sure what "background I/O" means, in this case. Application.library does sound like it could become a bit monolithic if left unchecked, but on the other hand, it could equally be 'just' the routines required to interface neatly/consistently to the OS at large... and if it does become a "system API in a box," at least there'd *be* a definite API?
