I'm not sure where the misunderstanding is being introduced, maybe you can elaborate with a question? Is there anything I said in my previous message that was contentious? Or any step in the reasoning which doesn't follow from the previous step?
• We provide common API for the vast majority of widgets. Common API is compatible across all platforms.
• For some widgets (like Dialog), there is insufficient consensus/confidence about the common API because of underlying/fundamental platform differences which are difficult to abstract.
• As a 1st-party vendor, we need to be super careful about which APIs we add, because are held to a higher bar in terms of making future changes and breaking people. This means that if there is insufficient consensus/confidence about the common API, we need to error on the side of caution and not publish the common code for that widget (like Dialog).
• 3rd-party vendors are not held to the same high bar, because users can more easily choose which 3rd-party vendors they want to add/remove from their dependencies. This means 3rd-party vendors can freely publish APIs even if there isn't consensus/confidence, because they are held to a lower support and stability standards.
• If a 3rd party vendor provides a common API for a widget (like Dialog), people can use that without implementing their own expect-actuals. This helps the whole ecosystem and can help mitigate the PITA problem you mentioned.
• If a 3rd party vendor provides a common API that becomes popular, that helps us have confidence in the quality of the API, and we can consider releasing a similar common API as an officially supported 1st party stable API.