`systemctl reenable` does not handle template unit files very well

Is your feature request related to a problem? Please describe.

systemctl reenable does not handle template unit files very well. Say I have foobar@.service installed in /usr/lib/systemd/system, and then I've run systemctl enable foobar@a and systemctl enable foobar@b.

Now say I want to override foobar@.service in /etc, so I create /etc/systemd/system/foobar@.service and run systemctl reenable foobar@, to update symlinks. Intuitively I would expect systemd to either error out and make me list foobar@a and foobar@b individually, or to reenable both template instances.

However, instead of doing that, systemctl notes that it's removing the symlinks for the template file instantiations, and installing a new plain pump.io@.service symlink in /etc/systemd/system/multi-user.target.wants.

Describe the solution you'd like

Template instantiations should be reenabled in a manner similar to what you'd expect.

Describe alternatives you've considered

As I mentioned above, systemd could also just error out in this situation? Honestly I don't understand template unit files, etc. enough to know what the right solution here is. It might also involve a completely separate command to update symlink locations.

System information

I'm on Fedora 28, which reports systemd 238.

Reproduce the behavior with the template unit and systemctl enable/reenable commands described in the issue, then trace how systemctl handles reenable for template instances. Done should be either correct reenable behavior for all enabled instances or a clear error explaining that instances must be listed individually.