renew_hook / deploy_hook INI setting wrong?

[emperortomato]

Up until today we'd been using v11.1.0 of this module to manage certbot on some hosts. I just updated a couple of our test environments to use v13.2.0, because I wanted access to the key_type parameter. I noticed that those hosts added a new deploy_hook key/value to their renewal conf, which is inserted alongside the existing renew_hook key/value. It looks like that's being done in this loop.

[renewalparams]
# Original, working key
renew_hook = /etc/letsencrypt/renewal-hooks-puppet/host.sh
# Nonfunctional key, as far as I can tell
deploy_hook = /etc/letsencrypt/renewal-hooks-puppet/host.sh

The problem is that --deploy-hook is supposed to translate to renew_hook in the renewal conf. I'm testing with a pretty old Ubuntu-maintained version of certbot (2.9.0), but it looks like the most recent version of certbot maintains this behavior, since it removes deploy_hook & replaces it with renew_hook if found:

    # MAGIC CODE ALERT
    # In keeping with the code in RenewableCert.__init__, we use deploy_hook internally,
    # but write out the value as renew_hook to allow downgrade compatibility.
    # So, if there's a deploy_hook (the internal name), change it to renew_hook (the renewal
    # config file name).
    if "deploy_hook" in config["renewalparams"]:
        config["renewalparams"]["renew_hook"] = config["renewalparams"]["deploy_hook"]
        del config["renewalparams"]["deploy_hook"]

Inserting deploy_hook doesn't appear to cause certbot to fail, but it will cause active Puppet runs as the key/value is removed by certbot and re-added by Puppet, and potentially service restarts if folks are using notify or subscribe to restart services when this module makes certbot changes.

Is the module intentionally inserting deploy_hook into the renewal conf for forward compatibility purposes, or is this a bug?