It seems like a property can't be forced to fall back to a string type, which results in an exception when a value can be parsed as a more specific type.
When using the following YAML, the Value property is correctly inferred to be a string (based on the first value that it sees, which isn't great but at least can be worked around), but it refuses to parse a value which can be converted to a URI.
This produces an exception reporting Cannot assign value of type Uri to field of Value: String.
Reordering the fields in the YAML template to put the URI first will cause it to infer the field to be a URI, which will then cause errors when it tries to read the string values.
I'd assume there are similar issues when mixing values which can be parsed as numeric values and other non-string types. The correct behavior would seem to be to pass unparsed string values to string fields, regardless of the perceived node type.
It seems like a property can't be forced to fall back to a string type, which results in an exception when a value can be parsed as a more specific type.
When using the following YAML, the Value property is correctly inferred to be a string (based on the first value that it sees, which isn't great but at least can be worked around), but it refuses to parse a value which can be converted to a URI.
This produces an exception reporting
Cannot assign value of type Uri to field of Value: String.Reordering the fields in the YAML template to put the URI first will cause it to infer the field to be a URI, which will then cause errors when it tries to read the string values.
I'd assume there are similar issues when mixing values which can be parsed as numeric values and other non-string types. The correct behavior would seem to be to pass unparsed string values to string fields, regardless of the perceived node type.