SOAP doesn't have anything like the restrictions rest has, does it?
At this point, we might as well call it RPC-style organized calls over HTTP using JSON representations and defined by "Swagger" files.
Likewise, most of SOAP was "RPC-style organized calls over HTTP (or TCP) using mostly XML serialization and defined by XSDs.
Yes I'm disillusioned with the unnecessary re-invention of the wheel here. And "REST" interfaces defined with gigantic OpenAPI documents aren't really all that better than SOAP, just with hip and still-in-development toolchains around them. It's all marketing and popularity contests, and SOAP/XML/XSD lost out.
I believe the triumph of REST over SOAP was mainly piggy-backed off of the triumph of JSON over XML (even though neither has technically anything to do with REST).
In practice, in most people's minds, REST == JSON and SOAP == XML and JSON > XML. Therefore REST > SOAP.
Though as you note, what most people today call REST falls way short of the whole singing and dancing HATEOAS bag that Roy had in mind.
(Personally I think hypermedia is way overrated for most APIs, though that's not an opinion many REST zealots are open to).
JSON is definitely not perfect and has similar problems with things like serializing maps with objects as keys, but it does have more opinionated ways for serializing things than XML does.
The answer to pretty much all your questions is "depends on the schema". There are XSD (XML Schema Definition) files that you can use to define types. You can define sequences, etc.
Then you can define a WSDL (Web Services Description Language) file which describes the RPC operations, arguments, return types, etc.
After that, you can use something like gSOAP to generate C/C++ out of the WSDL and XSDs. I think Java has a lot more variety in turning a WSDL into code, but last time I looked on the Java side of things it was super confusing. None of the tools seemed to work well together. They would never shut up about beans, and there always seemed to be a bunch of tool specific annotations. Pretty disappointing, and definitely makes me lean towards REST for personal projects, if only from a KISS perspective.
My impression is that SOAP and XML could probably make a much more complex web service than REST (again, abusing the term to mean JSON/HTTP). But after having worked on a pretty confusing contract-first web service, I am kinda jaded about it.
IMO much of that could be fixed with a JSON derivative that allows optional type identifiers before values. While you're there, guarantee support for comments and trailing commas, because despite design ideals, humans will write JSON manually, even using JSON for configuration files that are expected to be hand-modified!
We still use XML but its gone from RPC / everywhere to now only being a storage mechanism. I remember the network transfers dropping significantly and being very happy. Haven't looked back.