Do you suggest we indicate it's deprecated in 13 and then remove it before 14, or remove in 13?
i.e., what about one of these:
The .Nm utility is deprecated and will not be available in .Fx 13.0.
The .Nm utility is deprecated and will not be available in .Fx 14.0.
etcupdate is available in all supported releases
The timing is flexible I think, but my recollection of the current depricaiton policy is since no notice went out in 12.0 the first notice of deprecation should be in the 13 branch and the code is removed in 14. But as I said history has shown us to be pretty flexible especially if we get notice MFC'ed and it goes out in 12.2. So up to you which path you choose.
I do like the text you used.
Some further discussion has turned up a preference for removing in 13.0, and I'm happy enough with that plan assuming we get the notice in 12.2 and 11.4.
Add a few others who have touched mergemaster as subscribers.
I think removing in 13.0 might be a bit aggressive. I've certainly run into several developers who still use this instead of etcupdate. We also haven't updated any of our docs in the handbook to mention etcupdate (wblock@ tried but gave up when he ran into issues I didn't understand when trying to use etcupdate). I do think a runtime warning might also be warranted, though likely to be lost in the noise that mergemaster generates. Making sure the handbook documents etcupdate is probably a prerequisite for deprecating it.
Why though? Plenty of users still use it. What's the argument for forcing etcupdate over mergemaster? IMHO it's a large burden to users to convert things that use mergemaster fine to etcupdate.
What unsolved problem warrants removal? I assume the argument is "not maintained" which is why I ask what problem exists.
As far as I know biggest reasons are included in some PR's (252054).
mergemaster does not work nicely with VCid's being removed because of the git transition (13-release and higher).