Okay, let's get back to what is being requested here and in many other places, and most importantly //why// it is requested. The //only// reason this feature is requested is, ultimately, the constraints imposed by the condition limit of the abuse filter. If no such restriction existed, every one of these tags would already exist as global or local filters. But since the restriction exist, and for good reason, this can't happen.

Log-only and tag-only filters are always the ones that get sacrificed first; it has been like that since the introduction of AbuseFilter, see [[https://en.wikipedia.org/wiki/Wikipedia_talk:Edit_filter/Archive_3#Filter_Reduction|this June 2009 discussion]], and is [[https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Edit_filter&oldid=649616762#Condition_limit|just as true today as it was back then]] (the same holds on other wikis and even more for global filters). There's no change in sight, even if the condition limit can be legitimately criticized, some kind of limit must still exist.

Pretty much all of the potential autotags were added by now deleted abuse filters : [[https://en.wikipedia.org/wiki/Special:AbuseFilter/8|self-redirects]], [[https://en.wikipedia.org/wiki/Special:AbuseFilter/27|making/changing redirects]], [[https://en.wikipedia.org/wiki/Special:AbuseFilter/27|replacing content]], and so on. These can be easily inserted from mediawiki core, most of these edits already create automatic edit summaries. I was even thinking we may want to merge autosummaries and autotags in a single function, since the special casing is very similar.

What end users need is to have these easy autotags defined in core, so that abuse filters can focus instead on more complex tagging or other actions (warn, prevent edits). Therefore, this feature request amounts to a core-implemented tag-only AbuseFilter. The customization aspect is integral to AbuseFilter, and so it should be integral to this feature request. We should start from a level of customization that exactly matches the level of customization afforded by AbuseFilter, and narrow it down only when truly necessary for the implementation.

Now with regard to extensions, I wasn't mentioning visual editor at random here, as I said we had to create filters to keep track of visual editor bugs, see [[https://en.wikipedia.org/wiki/Special:AbuseFilter/577|AF 577]], enabled for months, which, however silly that might look, checked for insertions of ♙, ☃ or ↵, so not exactly adding the letter "A" or "B", but close ! Same problems occurred with wikilove and other extensions. These filters aren't cheap, extensions should rather make these debugging tags on their end. Some wikis may also want more involved autotags than those defined in core. So I wanted to let this possibility open for future implementation (so we don't tie our hands).

I was thinking of a hook that takes the same params as the autotags function and alters the autotags. If we had a config variable, the extension could add the extra tags to it and let end users do the activation/deactivation. Without it, the extension needs to provide a way for users to make the activation/deactivation. This means a user interface, so more work on the extension's side, when it can be done at Special:Tags. That being said, I'll keep this for later and only focus on core-defined tags for now. So basically the list of tags is hard-coded at ChangeTags.php instead of being provided as a config variable.