Currently users must specify the `notify` clone meta-attribute to `true` to get clone notifications. It's unlikely anyone disables notifications intentionally (which would be worth some investigation), so we should probably default to sending notifications whenever a resource is cloned and its resource agent supports `notify`.
We could change the meta-attribute default to `true` (and potentially deprecate it), or we could drop the meta-attribute and rely on the `notify` action's `enabled` meta-attribute to decide whether to send notifications (potentially with an XSL transform to preserve the existing configuration's behavior).
This would change behavior of existing configurations, so it should be done at a major version bump.
## Implementation
The scheduler doesn't know resource agent capabilities, nor is there a good way to pass them to it, so the likely implementation would be for the scheduler to always schedule notify actions for clones, and have the controller treat them as no-ops if the agent doesn't support them.
This would make transition graphs unnecessarily larger when the agent doesn't support notify, so we would have to check what difference it makes in a large cluster with multiple clones.