Thanks for reporting.

I also think that it's better for most workflows to do not replace already-existing Tags from a previously created form. The ?tags= parameter should just add Tags to a Form, without replacing.

Good points:

• you don't like the already-existing Tags in the Form, it's OK to suppose that you probably need a different Form
• the user can always manually remove Forms, while adding them back is a pain indeed.

Bad points:

• one could propose to add a 10000% compatible solution, adding another parameter like ?additionalTags=, so that it never replaces Tags in your already-prefilled Form, and so, instead, the ?tags= may be kept untouched, to behave just like before (as it always has operated in Phabricator / Phorge, so, replacing Tags). And, the T15147 may operate using ?additionalTags= instead.
  • but an ?additionalTags= would be a new feature, boring to be documented, maintained, making weird URLs for the sake of no known workflow.
  • also, if people don't like the Tags in a Form, can just remove these Tags from that Form and save, or duplicate the Form T15483, or just adopt whatever other standard form without prefilled Tags.
    • So this ?additionalTags= feature would probably be more confusing than useful.

So I'm also inclined to improve the behavior of ?tags=, so that custom Forms keep their Tags, and these expressed in the URL are just added Tags.

What if it were possible to intentionally remove a tag by passing the tag prepended with - to signify removal? like ?tags=-ABCDE to remove a tag but otherwise the behavior would be to just append. I realize this doesn't have the same compatibility advantages but it does offer slightly more flexibility for use in ad-hoc workflows.

Yeah so we are all for "let's just append as default and maybe think about something more for the future, if they ask"

In T15653#13929, @valerio.bozzolan wrote:

Yeah so we are all for "let's just append as default and maybe think about something more for the future, if they ask"

Yeah I think that I prefer making the best solution over backwards compatibility. In my opinion just appending is the best solution for the default behavior. We should try not to break anyone's workflows if possible but I'm not sure how changing to append would actually be worse than the replace behavior.

If someone comes along with a situation we haven't considered then we could try to accommodate with one of the ideas suggested here or something similar.