I plan to revisit this feature, as such administrative task should not be implemented as a builder arbitrary user configure on jenkins.

A simple option could be for the template to use a variable for image name, this variable being updated when image is rebuilt. Another more docker-centric approach would be to define image by it's sha256, not just tag, and get some hook to tell jenkins this image has a new build with updated sha256, so jenkins will use it for new build. When image is built within Jenkins we could then automatically trigger this update.

I agree that this is a privileged operation that should be out of the reach of normal users.

I'm not keen on the plugin storing the sha256 of the selected image - I prefer docker looking things up by name:tag.  As a Jenkins administrator of multiple servers, I want to be able to replace one container with another purely by re-tagging, without needing to reconfigure all my Jenkins servers to tell them to look up the new sha256 that the name:tag now points to.

FYI my use case (and possibly for other people too) for this kind of functionality is that I've got teams of developers (our "normal users") whose builds run on docker container slaves, and another DevOps team who look after the Jenkins server and the docker images.  The DevOps team want the ability to automate the updating of the docker templates in Jenkins.

Ideally, I'd like to be able to have a build not only create (and publish to our docker registry) a new docker image, but to also be able to programmatically determine what "tags" the image should have and configure Jenkins with that new information.

At present, we can either update the templates manually, or we could do it using some groovy script running on the Jenkins master, but the former is manual (not automated) and the latter is non-trivial (and largely undocumented).

However, we've been surviving without this feature for over a year now, so this is a low priority for us.

Since the plugin was changed to store docker image names & tags rather than their hash ID (some time ago now), it's no longer necessary to update the template at all - we just build a new image, upload to the registry, then tag it as the old name.

i.e. This has become a non-issue.

Just stumbled across this one and wonder why it has been closed. The template doesn't only consist of an image name and tag. It's much more, like volumes to mount into the container or credentials for launching the Jenkins agent, etc. So if I add another volume to the "Create docker template" build step, I'd expect it to update the template in each configured Docker cloud. I would be fine if such updates need to be allowed by an admin or via an additional checkbox in the build step config.

It was closed because the original author of this RFE (that's me) didn't need it anymore and therefore didn't have any inclination to implement it. There were (far) more important issues to concentrate on, and this wasn't one of them.
The blocking issue with any bugfix and/or enhancement with FOSS is (usually) to have a software coder who is both capable of implementing it and also keen to have it; I decided that it wasn't going to be me (so I closed it), but if you (or someone you can persuade) fits those criteria then please do get involved

FYI, when I originally raised this issue, Jenkins pipelines weren't the big feature that they are now; if I were to need to update a docker template today, I think I'd write code to do that in groovy within a Jenkins pipeline.
The big problem to solve in order to make this RFE viable is to work out a good way of identifying which template(s) need to be updated - there's no requirement for a docker agent's template "name" field to be unique across all templates, so that gives us the problem that there is no (good/easy) way of unambiguously identifying the template(s) to update. When I originally raised this RFE, there wasn't even a name field in templates (the nearest equivalent was the "docker image", but it's perfectly reasonable to have more than one different template using the same image, so that's not unique either...)
The next problem would be how to create a means of updating any/every part of the template without causing massive code/data duplication - we don't want to make the plugin code more difficult to maintain...

Overall, this could turn into a non-trivial bit of work - it'd need all sorts of functionality for "how to identify what templates to affect" as well as lots of (boring but easy to get wrong) code to allow users to add/remove/replace field values, and that's even before we get onto permissions issues of limiting who could trigger this.

...that said, if you believe that need this, feel free to re-open it (or raise a new issue on github) and detail the exact functionality/requirements/use-case(s) you're after ... and then, once the overall approach/design is agreed, be prepared to implement and submit a pull-request for it so the code can be reviewed