Inconsistencies in property handling compared with ARM

Summary of the new feature / enhancement

DSC and ARM are handling properties in an inconsistent way. DSC assumes that all properties consumed or generated from a resource are under the "properties" property. Only these properties are passed to the resource on set/test and any property generated by the resource are placed inside this property.

In ARM, there are properties that are expected/allowed outside of the "properties". For example, all resources are expected to a "name" property outside of "properties" and this property is part of the unique ID of a resource. It is NOT just a human readable description of the step in the template.

Other properties that are allowed outside of the "properties" property are "kind", "sku", "plan", "systemData", "managedBy" and "tags" (and possibly others that I am forgetting). These properties are considered as part of the payload of a resource and are expected to be passed to the resource on set/test and returned by the resource on get.

Proposed technical implementation details (optional)

No response

Start by examining how DSC currently handles resource properties and compare that behavior with the ARM conventions described in the issue. Define the scope for properties outside "properties", including name, kind, sku, plan, systemData, managedBy, and tags; the work is done when set, test, and get consistently handle the agreed resource payload.