Binary > text. Seriously.
We can parse it faster because it’s smaller and requires less code as well. It does require thinking about the future though and some of those unused bits are the key: one could easily add colour but that says the colour is a negative offset in the file giving us some easy dictionary compression if it looks like it’ll be a win.
Haiku has done some really interesting stuff. The vector icon thing is cool, and the package filesystem is breaking new ground in package management. BeOS was my favorite OS of all time (but don’t tell AmigaOS I said that…).
(I will say, though, they Haiku is suffering from second system effect. They also, IMHO, made a mistake in demanding binary compatibility with original BeOS. If they had just gone for source compatibility, they would’ve been finished ten years ago…)
Another downside they forgot to mention is that vector images are harder to downsize. With bitmaps, you know exactly what value each pixel will have, whereas with vectors you have to lay them out so the image will still be crisp at small sizes after antialiasing. This is what makes good font design more constrained on low-resolution screens, and why most fonts contained a bitmap for each character before screen resolutions got bumped up.
That’s what caught my eye in the second image. The 16x16 bitmap version looks much better, imho.
I know hinting is a thing for fonts, but can it also be included in SVGs? I feel like that’s exactly what is needed here.
The tiny size is so it’ll fit in the filesystem as metadata, otherwise it’d be an extra seek. Are there really so many icon types that a simple cache wouldn’t work? I’m all for cool stuff like this but it seems like a solution in search of a problem.
Opening /Applications regularly took a second or two to display all the app icons when I still had a spinning disk. Note that OS X has a few more layers of indirection: from the inode of the .app directory to the Info.plist of the bundle to the icon in the .icns file.