I'm happy and scared at the same time.
Also, someone has mentioned that this is really pandering to the type foundries who aren't willing to modify their business models and their licensing to accommodate web usage. Maybe this is a good first step or maybe it's a RIAA thing for the fonts.
I thought it was interesting, though.
Since they are using CSS font mechanisms (I think), it will depend on what the CSS engine does. If it completely can't get a font, presumably it'll use the same fallback rules it already uses when you call for a font that isn't there. The interesting question is what exactly the browsers do for such fonts, but my guess is that they would be treated exactly like a script tag in the header, adding something that would have to be downloaded before the page will even begin to render. But, further presumably, the JS they provide and the fonts will be properly labeled with cache control headers so they don't hit the host server on every page load.
See how Yahoo serves their YUI stuff: http://developer.yahoo.com/yui/articles/hosting/
The question is what defines "can't get a font completely". Is it a timeout? How long is this timeout? If I spend time and resources to optimize the loading time of my site and the JS script times out getting a font, isn't that lost time for me?
This all feels like a workaround for license issues as opposed to a true solution. Type foundries should let web developers purchase fonts that can be published on the web.
2. Render.
3. Is font available? If yes render, if not, use next font.
If that download is taking forever, I'd imagine the page would render in the secondary font until the Load font command is eventually successful.
At the end of the day, the web really is mostly type.