We want to use HTML5 date fields where we can, but there are going to be a lot of issues.
There are a whole list of possible fields to use: date, datetime, datetime_local, week, month, etc. (see http://www.w3.org/TR/html5/states-of-the-type-attribute.html#date-and-ti...)
If you go to http://html5test.com/ and test various browser support, you can see that none of the HTML5 date fields work reliably across desktop browsers. In fact I only found one desktop browser that supported any HTML5 date field -- Chrome supports the 'date' type but nothing else.
These fields are really only supported on mobile devices.
We have a javascript calendar popup that does work on desktops, so we still need to provide for that. But it has to be done in a way that we can use the hmtl5 widget where available and then degrade to the jquery popup, and finally degrade to a textfield if neither html5 nor jquery will work. I see http://drupal.org/node/1179520, which indicates there is some handling of poor IE8 html5 support using htmlshiv, but I can't tell if that will help us or what it will do.
I discussed this with some core maintainers in Munich, and the initial idea was that core would not provide any backwards compatibility -- it will be html5 or nothing. I think that's going to be a poor desktop UX, but that's just me. And I suppose somewhere between now and when core actually ships a production-ready version maybe desktop browsers will catch up.
So we need to use html5, but also recognize that it often will not work.
The date module currently creates date_text, date_popup, and date_select elements, each of which need to be examined to see how best to include html5. I hope we can then get them into core.
The date_select widget would not have any html5 settings, so it will work the same everywhere. The current date_popup expands into a 'date' and 'time' field, where the 'date' element uses the jQuery datepicker. That element could be reworked to use a html5 date element, but we need to clarify the fallback behavior so the jQuery widget can be used on all the desktop browsers that don't support html5 date. The time element could either become a drop-down selector, or become a html5 time element. We currently have a jQuery timepicker on that element, so again we have to figure out fallback behavior. The current date_text field uses no jQuery, so it could be configured to be a html5 datetime element.
Some relevant issues I found:
http://drupal.org/node/675348
http://drupal.org/node/1183606
http://drupal.org/node/1529390
http://drupal.org/node/504524
http://drupal.org/node/1496708
http://drupal.org/node/1496652
http://drupal.org/node/1328650
http://drupal.org/node/1189804
More HTML5 browser info:
http://www.quirksmode.org/html5/inputs.html
http://wufoo.com/html5/