I saw the same thing when working with PHP consuming data from a SOAP endpoint. First I thought PHP is stupid. But then I realized that XML can’t model single item arrays versus single objects. They look the same. JSON is better that way. You can model empty arrays and single item arrays.
<results>
<result>
<property>value</property>
...
</result>
</results>
[
{ "fruit": "banana" },
{ "color": "yellow" },
[ 1 ]
]
<document>
<fruit>banana</fruit>
<color>yellow</color>
<ids>
<id>1</id>
</ids>
</document>
I'd generally prefer to work with JSON, too. But the silver lining of XML is that you can define virtually any schema you want, and there are times that's conceivably going to be clearer or even more concise than the equivalent JSON.
So an array of two results looks like this:
<results>
<result></result>
<result></result>
</results>
<results>
<result></result>
</results>
<results>
<result></result>
</results>
That's not a problem in what XML is able to model, it's a problem with you throwing the information you got away and then pretending you didn't receive it.
On the other hand, if you meant that you get a single "results" object, then you're saying that your code is written to require invalid XML and fall down when valid XML is provided. Again, that sounds more like a problem with your code than with the modeling capabilities of XML. There's an argument to be made for accepting invalid input; rejecting valid input is ridiculous.
Looking at the XML when a list has only a single element, you wouldn't know if there could be more. You need an XSD to accompany the XML, which is what is typically provided.
When looking at a JSON document you might run into the same situation where the document you received doesn't contain all possible elements, and you wouldn't be the wiser. You'd still need a proper JSON schema to accompany the document.
if ismissing(x) then
x = empty
end if
if isempty(x) then
x = ""
end if
if x is nothing then
x = new foo
end if
if right(typename(x), 2) <> "()" then
x = Array(x)
end if