Comment 4 for bug 2003121

"it's expected that cloud-init will ensure that machine-id is not carried over when a VM is cloned and this is detectable by an instance-id change."

I'm not sure that statement above is wholly correct.

The instance-id delta is triggered in more cases than just a clone and first instance boot event.

In recent history ~5 years, some clouds trigger instance-id changes for the following events to force cloud-init to reperform all configuration on next boot (or sometimes hotplug NIC configuration):
 - network configuration changes, NIC add/remove
 - user-data changes or vendor-data changes
 - vm clone and cloned image relaunch

Here is systemd's documented stance on machine-id changes per man machine-id:

The machine ID does not change based on local or network configuration
       or when hardware is replaced. Due to this and its greater length, it is
       a more useful replacement for the gethostid(3) call that POSIX
       specifies.

Trying to fold /etc/machine-id regeneration into every instance-id change for cloud-init will be tough to support until we have:
  1. cloud-init grow smarts to perform a comparison of previous cached instance data versus current metadata from the cloud's instance metadata service to determine whether the scope config changes are limited to just network or storage to avoid regenerating the machine-id unnecessarily 2. an assurance that systemd and systemd-networkd can react appropriately to an updated machine-id on the booting system after networkd is already active comes up

The reason for #2 is because cloud-init is only able to detect instance metadata after the network is already active on the system, and restarting systemd-networkd later in boot is more likely to expose a number of other racey problems.

We may take a look at this further, but the conditions under which we want cloud-init to magically regenerate /etc/machine-id and cope with systemd ordering/costs would need to be limited in scope to avoid triggering other concerns.