Questions on ARIA and HTML interactions for aria-required and aria-invalid

We've come across a couple of places where it's not entirely clear what should happen with ARIA markup in HTML 5.  We're hoping for a quick turn-around on these questions if at all possible.

1) Aria-required

<input type=text required aria-required=false>
The html "required" attribute would win, and the element would be mapped as required in the Accessibility API. The string "aria-required=false" would still be copied to the AriaProperties property in UIA and the Object Attribute in IA2 and ATK.  I would also consider this to be an author error.

Less clear is this case, where the HTML "required" attribute is not present.
<input type=text aria-required=true>

The ARIA spec says
<blockquote>
The aria spec says:  http://www.w3.org/TR/wai-aria/states_and_properties#aria-required
Unless an exactly equivalent native attribute is available, host languages SHOULD allow authors to use the aria-required attribute on host language form elements that require input or selection by the user.
</blockquote>

Does "available" mean that the element supports that attribute, or that the attribute is present in the current instance of markup?

http://dev.w3.org/html5/spec/wai-aria.html#wai-aria
Required is listed as having strong native semantics in the HTML 5 spec.  Does that mean that aria-required is always ignored on elements that support @required, or that it is ignored when @required is present in the markup?

The ARIA User Agent Implementation Guide says
http://www.w3.org/TR/2010/WD-wai-aria-implementation-20100916/#mapping_conflicts
<blockquote>
When WAI-ARIA states and properties correspond to host language features that have the same implicit WAI-ARIA semantic, it can be particularly problematic to use the WAI-ARIA feature. If the WAI-ARIA feature and the host language feature are both provided but their values are not kept in sync, it is uncertain which one is correct. When a host language declares a WAI-ARIA attribute to be in direct semantic conflict with a native attribute for a given element, user agents MUST ignore the WAI-ARIA attribute and instead use the host language attribute with the same implicit semantic.
</blockquote>
Which is still unclear as to whether the feature must be ignored when the related host language feature is supported but not present in the markup.


2) aria-invalid
This case does not seem to be explicitly covered in either spec.

<input type=email value="not email" aria-invalid=false>

The value of the element is not a valid format for the input type, so the browser would consider it to be invalid.  Does the aria-invalid=false override that, so that the accessibility tree node would be marked as valid?

Thanks,
Cynthia