In a lot of ways you outlined a hefty chunk of what's WRONG with HTML 5.
Except is that type of semantics even warranted on 99% of the sites people are going to put it on? Does ANYTHING MEANINGFUL really care about the last microsecond of detail on the time. The TIME tag strikes me as being akin to TITLE attribute idiocy; where most of the time if you need TITLE, there's something wrong with the contents of the tag you are applying it to.
ADMITTEDLY, there is the whole America vs. RoW time issue of what comes first, month or day; But the solution to that if you care is to spend the time to shock spell out the month. We have computers, we can do that automatically now. "j F Y" FTW.
How so? Extra inline-level phrase-type elements doesn't make it more legible because it breaks up content that probably shouldn't be. So many of the existing tags go unused either out of ignorance (DEL,DFN,KBD,SAMP,VAR,TH,LABEL,CAPTION,LEGEND,FIELDSET), bashing them into 'specific roles' making them useless for anyone (ADDRESS), or people just being too stupid to figure out which witch is which (ABBR,ACRONYM) -- throwing MORE phrase, structural or special elements in is NOT the answer.
... missing the point of using them -- NOT changing the content's existing meaning. Natural language and formatted data so far as USERS are concerned shouldn't NEED extra semantic tags for each and every little stupid case. That's just making more work for developers for no real tangible benefit. We keep this attitude going, by the time of HTML 10 we'll end up having wrapping every blasted word in it's own tag just so we know what type, tense and variation is being used. <pronoun personal="personal">I</pronoun> <verbaux tense="present">can</verbaux> <verb>see</verb> <pronoun>it</pronoun> <adverb>now</adverb>....
Putting many of the new tags squarely into the same bin as all that microformats asshattery -- except instead of abusing abbr we're making the spec more complex than it needs to be. It's like all this metadata crap many OS try to add to files that NOBODY actually has the time to bother filling out -- unless you can automated like with MP3's it's pointless. (trust me, as a former BeOS user I've seen it in action) -- Most DEVELOPERS can't even be bothered to use verbose names for ID's, classes or filenames, much less the cryptic "What the devil does that mean" normal people use for their files.
Which is another hefty part of my issue with HTML 5-- what in blue blazes does that have to do with Markup?
An HTML specification should be about writing markup -- a scripting specification should be about writing scripts -- a CSS specification should be about writing CSS.
But they've thrown it all under HTML 5's banner because without those extra things, it would be meaningless rubbish that serves no point... and since you can use CSS3 and the new scripting WITH HTML 4/XHTML 1, what's the POINT?!?
Again, which has what to even DO with writing markup?!?
Let's go down the list of these 'features'.
AUDIO and VIDEO -- Redundant to OBJECT, locks us into supporting whatever pet codecs the browser maker wants to shove down our throats and locking out third parties from introducing their own to the browser... The fractionalization of video formats I predicted back when the Ogg whackjobs were touting VIDEO as the greatest thing ever has actually come to pass. There is no legitimate excuse for these to be new tags, or that the scripting that makes them desirable over object could not have been added to the existing tag. A new universal plugin format and forcing browser makers to sandbag their plugins (like chrome does) would have been MUCH more helpful.
CANVAS -- Shouldn't even HAVE an element since it's JS only... and if you bother having capabilities detection you're already building it's context on the dom before adding it; at which point is one more createElement really gonna kill you? This would have been much more useful if it could be attached via script to ANY element.
SVG -- Remember when Adobe was the champion of SVG 13 years ago (since it's loosely based in part on Postscript)? Of course not! They torched it, pissed on the ashes and buried it in a deep dark place the MOMENT they bought out Macromedia. SVG is one of those 'pipe-dream' formats that fails to deliver on it's promises by being needlessly complex, needlessly verbose, and too difficult for the average person to even THINK about using despite it's alleged "XML simplicity". It's been around for as long as HTML; and it's gone NOWHERE for a reason. People are trying to use CANVAS instead because they can at least wrap their heads around it... which is sad given that CANVAS isn't exactly simple either.
LOCALSTORAGE -- because after years of people complaining about cookies storing information, now we're going to be able to store even MORE crap on a users machine. Possibly handy for apps, potential for abuse massive.
DB -- ditto.
GEOLOCATION -- I don't get the appeal/need for this. But then anyplace you should really 'need' geoloc you probably wouldn't have coverage anyways. Could be cute for making
NOT even sure what that means... could you elaborate?!? "Switch keyboards?!?" on mobile?!? You've lost me.
THOUGH, the inclusion of 'required' and others is welcome because if they aren't present/functional, big deal. Validation is one of the things I do welcome; BUT -- I'm worried about all the people who will think it can be trusted and fail to provide fallbacks.
Because after twenty five years since I first encounted "ready for real world use" speech input, it has improved by leaps and bounds to where it's ACTUALLY ready for real world use -- NOT.
The most what?!?
Though again, what's that got to actually do with writing HTML? NOTHING.
Define 'everyone' -- as I think we have a different definition!
Complete lack of versioning, no link to the defining document, completely discarding the mechanism that was put in place so that browsers could automatically support new doctypes -- that not one browser maker has gotten off their asses to implement properly? But no, let's go for this 'living document' crap, throwing out any chance at providing consistent baselines and readiness states. All it does is the lip service feel good "look we're using less characters" without taking the time to think about why the original was so 'large'. Besides, if the size of the doctype was causing a significant impact on how long it took to write a page, deploy it to users, or any of the other lame excuses used to justify said shortening, there's probably something disastrously wrong with the page it's being applied to.
Again, you can tell nobody with an engineering background is even remotely involved in HTML 5's creation.
90% of which work just fine WITHOUT HTML 5 since there's nothing stopping you from using most of the new scripting goodies and css3 'gee ain't it neat' stuff in a HTML 4 / XHTML 1.0 document. The only things you lose in terms of the 'rich content' are AUDIO and VIDEO, which to be frank we need to start standing up to the W3C and Browser makers and tell them what we REALLY need to tell them.
NO MORE VENDOR LOCK-IN!
Which is funny since that's what they claim those new tags were added to fight... RIGHT. Apple must love it though, they've been all about vendor lock-in since they day they introduced the Lisa.
Though to get back on track, you pointed out all the really useful bits of "HTML 5" -- too bad most all of them have NOTHING whatsoever to do with writing HTML. You take those away, and there's no longer even a reason to HAVE a new HTML...
Bottom line, "Newer isn't always better" -- and when they have to hide their idiotic rubbish changes to the markup behind other specifications that have nothing to do with marking up content; well, does the term snake oil ring a bell?