I'm unsure about the Attributes and metadata, mostly that those should not be relied upon by the adapter, since it should be defined in the resource manifest.
@michaeltlombardi don't we think that should be done by the resource manifest anyway, and the attributes are only relevant to generate the manifest? (so they're out of scope for this RFC, but the manifest metadata should be in-scope and clarified here?)

Another thing I think is missing is how we could get the same outcome as the Machine Config "reasons".
I think the return object [System.Tuple[bool, <ResourceClass>, String[]]] is simplistic, or should at least explain how the [string[]] are used/displayed through the adapter and engine.

After going through the RFC a couple of times, some small remarks from my understanding of it:

• In the skeletons, I still see Ensure is (still) the word. Even though many DSC resources will use this (also for backwards compatibility), I think it would be better if they followed the semantics of Microsoft DSC to start implementing Exist, knowing that the DscResourceProperty() attribute isn't going to be an optional one in this case. If "they" need to reshape the class anyway with static methods, why not include this one directly...
• In case of classes going through the adapter, the Validate needs to be properly implemented to validate the schema (I might be missing something here as I couldn't imagine the part on: If the resource doesn't implement this method, DSC generates a JSON Schema by inspecting the resource class itself.) .
• I think the RFC also needs to include the logging part, meaning: how can resource authors hook into the logging semantics of DSC (especially because of issue: Output during module import or output from Get operation interrupts the parsing process for class-based resource #833)

Todo: update with the what-if scenario #1361