Chris Glein

> I would keep the Property-Property and I wouldn't introduce a new Path property on the Setter class. To access elements, I would create an additional property on the Setter...

> This feature means that the code of many developers will have dependencies to the named elements that are inside the ControlTemplates. This is definitely true, and should be handled...

> That being said, I don't have a good scenario that I can come up with at this time for why we would want to do the "dot" method -...

> Silently not applying is fine, but it would be useful for debugging if there was a warning when style elements will not apply because of a mis naming, or...

We should align our API to the one coming so we don't incur a breaking change later.

> @chrisglein that was the intent behind this issue - is that not clear? @kikisaints Looking at it now, yes. Not sure why we felt the need to restate that...

@kikisaints contributing that back sounds like a great idea, although that sounds like we'd want to pair that with changing over from AppTheme to Appearance so that we don't leave...

Note that in #4322 the AppearanceModule is implemented. But we still need to reconcile that with what we already had. See notes in that issue.

High contrast support doesn't existing in `Appearance`, so we need to keep `AppTheme` around temporarily just for that, until we upstream it somehow. https://microsoft.github.io/react-native-windows/docs/apptheme-api - getCurrentTheme() - isHighContrast() - currentHighContrastColors()...

First question is how is this handled upstream with RN core. Are these types supported by their native codegen? And if not, what does it means for Windows to not...