I was figuring out the approach you suggested and realized couple of things.
It would also feel as a hack for custom cargo users to use 'cargo.properties.file' because they have the total freedom to choose how to fill up the properties. ANT people have used to http://ant.apache.org/manual/Tasks/property.html style of file referencing and mojo's seem to use surefire's approach so this feels like a poor compromise. I think that the strong point of cargo is that it generalizes different containers without generalizing the tooling (those mojo's that are made using ANT task's give usually no extra value compared to using antrun plugin directly).
I noticed also what you proposed would't cover system properties and for them a similar solution would require also patching of AbstractInstalledLocalContainer which would increase the complexity even further. The embedding is done at mojo level so serious refactoring would have to be done in order to push that down to API level as well.
Maven has also a notion of user properties that is those under -D switch. I didn't include to the patch but the idea is that although cargo container might be interested to system properties of maven execution, the delegation would need to restrict on explicitly defined system properties to avoid situation similar to
SUREFIRE-491. This is easy to implement at the mojo but would increase complexity if it's delegated to API level as well.
I'd hope you reconsider the patch but in the for me it's quite same how to get the job done. I could even do it at my custom config but this approach just felt smarter.