"Created" and "Modified" dates not set properly on item duplication

Thank you! It's definitely helpful to offer more meaningful feedback to first understand some of the reasoning behind a decision.

As to that most common use case... yep, I've done that, too. However, at root, these use cases are really about access control, and the use of copies is merely a workaround for lack of better functionality to solve the problem at hand. Data duplication for access control is a terrible practice even for basic users -- multiple, independent representations of the same secret is a sure path to confusion down the road and can easily lead to accidental account lock-outs and other problems -- so instead of encouraging it, 1P should offer solutions to the underlying challenges.

For the short-term version of this problem, 1P has done just that. These are cases when, for example, you want to give a wifi password to a friend, and they're addressed by the recently released web-based sharing feature where one can share an item without requiring the recipient to sign up for an account. It was waaaay overdue, but it's a wonderful implementation that perfectly solves the problem, with no data duplication in sight.

The long-term version of the problem is still present. Think, a team that needs to accommodate a contractor on a particular project, or the family who wants to share some accounts with a foreign study student residing with them for a few months. What's needed here is to share a handful of items scattered across existing vaults without blowing up the vault organization (which can't even solve the problem in some cases) -- enter item copies as the solution. Which, well, sucks.

As to the custom template feature, I'm very much looking forward to it, but it's not a whole solution. There are two primary reasons I use copies as a "template clone", as you called it. One is the situation that custom templates would solve, namely, when I want to define a new type of item. For example, I might want an item type to track combination locks with a serial number, description, and combination. Going forward, I'll periodically create independent new instances of this item type.

The other case is just to shortcut data entry time on an ad hoc basis. For example, maybe I just bought one of those software bundles that sites like MacUpdate sells, where you get 10 or 15 apps in one purchase but you still register them separately. I might register the first app and record all the purchase details in 7 or 8 fields of the item, then as I get around to registering the others, I'll duplicate the first item, edit the app name, serial number and publisher information, and leave all the purchase details. An example on the biz side is when a dev or QA team is creating a bunch of test accounts that share URLs and other info. In all these cases, the goal of the copy is just to save time in the moment, not to make a template to reuse in the future or share with others. (I don't think custom templates would even work here, since values also need to be preserved, not just fields, but it's been a long time since I looked at the feature.)

Speaking of a long time, there's also the small matter that custom templates transitioned to vaporware a long time ago, at least in GA guise. I mean, it's been in beta for, what, six, seven years now? And only on the business side, to boot. You folks just did an entire rewrite in far less time. The feature has obviously had a very low priority.

The Watchtower point is a good one. Interestingly, when I use copy as "template clone" feature, I always replace the password. Which makes sense - I'm using copy as a starter shortcut, not for access control. That also explains why I don't want the field histories in there.

Maybe what's really needed for my use case is a slightly different feature. YouTrack, an issue tracker I use at work, has a "clone issue as draft" feature that could fit the bill here:

https://www.jetbrains.com/help/youtrack/standalone/Clone-Issues.html

If 1P offered a similar feature, it would make a shallow copy of the item (no history) in unsaved state and dump you right in edit mode on it; canceling the edit would leave you without an item. The password would be cleared to discourage reuse and maintain full accountability from an audit perspective. Basically, this feature would be a shortcut route to a new item with its own audit history. This would actually be a great feature for my workflow, and it would allow the Duplicate feature to maintain its newfound purity.