With regard to "5. For forward compatibility with new WAI-ARIA properties in future versions, user agents should expose all properties not in the table below as a text string, removing the "aria-" prefix from the name, if the API supports it. For example, aria-foo="bar" would be exposed with a text string foo=bar in UIA Express, since aria-foo is not a currently known WAI-ARIA property". 

Comment: Why should user agents make such an assumption and present the aria-foo attribute without 'aria-' ...itmay lead to validation errors and is something best brought to the author's attention for correction. The foo="bar" should not trip up future AT unless they are made to ignore attributes that do not appear to make sense. User agents should simply ignore aria-foo and such.
Developers do have access to Nu Html Checker which flags incorrect use of role and ARIA attributes too I believe.  

With regard to "6. Some WAI-ARIA properties are not global, and are only supported on certain roles. If a non-global WAI-ARIA state or property is used where it is not supported, user agents should not map the given WAI-ARIA property to the platform accessibility API. For example, if aria-checked="true" is specified on <div role="grid">, it should not be exposed in MSAA implementations as STATE_SYSTEM_CHECKED. User agents may expose non-relevant attributes as a text string if the API supports it as described above".

Comment:
What is the benefit of user agents exposing a given ARIA property  as a text string when it cannot be mapped to the platform API?
It may trip up AT and confuse users. 

Perhaps the above mapping rule# 5 and 6 are inconsistent with the goal stated in the abstract?:
"This helps users with disabilities to obtain and interact with information using assistive technologies. ... and helps to ensure that this information appears in a manner consistent with author intent".