Having profiles merge rather than override just for this one key would make things quite inconsistent.
There’s also the issue that while most people use the YAML #cloud-config format, cloud-init actually allows many more formats which cannot merge as easily (the key could store a raw shell script, a base64 archive, a multi-part entry, … don’t remember exactly what’s supported, but there are many options).
Instead we’ve been pushing for the cloud-init team to start by implementing a native LXD provider module. This will have cloud-init use /dev/lxd to retrieve the LXD configuration rather than relying on file templating to dump data into place.
Once that step is done, we’re hoping to transition user.user-data, user.vendor-data, user.meta-data and user.network-config into their own cloud-init key namespace to indicate actual 1st party support of this.
That cloud-init provider code could then most likely be made to inspect all of the cloud-init keys and allow for something like:
cloud-init.vendor.foocloud-init.vendor.barcloud-init.vendor.bazcloud-init.vendorcloud-init.user.foocloud-init.user.barcloud-init.user
with cloud-init itself handling the merging and figuring out the application order.