It looks to me like your "nested resource" is closely analogous to a secondary resource as described in RFC 3986. Which is to say, it's just a bit of named information enclosed within the representation of the primary resource.
For instance, in this URI
The fragment "section-3.5" identifies a secondary resource within the representation of https://www.rfc-editor.org/rfc/rfc3986
We perform edits on the secondary resource using the semantics of edits to the primary. For example, if I wanted to fix a spelling error in section-3.5, I would POST/PUT/PATCH the changes to https://www.rfc-editor.org/rfc/rfc3986.
What REST/HTTP don't tell you is how to design your resources. Should there be one resource, or many? Should information about cars be included in the representation of person as a secondary resource, or should it be in a separate primary resource that is linked from person, or both?
The best heuristic I know of is to ask: how would you do this on the web? Would you prefer one HTML form for submitting the person, and then another web form for submitting a single vehicle? Or one web form that accepts all of the information in one go? Do you want one web page that shows all of the information? or several pages linked together?
There's no single "right answer" here, just a bunch of different trade offs (mostly centering around caching).
If there is a person with cars, what should be the behavior of PUTting a person? Should I include their cars in the PUT /persons call or should I only allow adding,updating,deleting cars in the POST,PUT,DELETE /persons/:id/cars call?
PUT /persons should have the same semantics as it does for every other resource on the web; it is a request to replace the representation of /persons with the representation included in the payload of the request.
What this message means is "the next time somebody requests GET /persons, there shouldn't be a cars member"; in other words, exactly the same thing that would happen if we were just writing documents into a dumb document store. That's the point of "uniform interface" - HTTP messages have the same semantics no matter what the target-uri is.
(What the server chooses to do with that request is a separate question; you don't have to satisfy every request you receive, and you don't have to fulfill the request the same way that a dumb document store does. You do have to describe your response using the same semantics that a dumb document store uses, and so on.)