Well, I suppose the only place to take this is WP:AIN. I expect that doing so will result in walls of text there. I took a look at their talk page for prior similar issues and found many going back more than five years. There are no archives, so one must go through the page history to find deleted discussions.
The talkpage documents a history of ignoring consensus when the editor disagrees with a policy/guideline, shows a disdain for established WP procedure for determining consensus, and a general acerbic attitude when questioned.
The following are excerpts from the talk page. For brevity, I have quoted the editors responses on a variety of subjects.
1. Changing dashes:
"Professional typesetters don't do it that way, and the MOS:DASH decision by a tiny committee of four or five didn't take into account how Web browsers work"
"The WP:MoS article you cite was written in a vacuum by individuals who apparently have no idea how Web browsers work and don't know (or care to know) that HTML is for content control, not formatting control. HTML was never intended to be a desktop publishing tool. In my experience since 2004, trying to get such misconceptions corrected in Wikipedia is like trying to empty the ocean with a teaspoon, i.e., a useless endeavour. I use a script to routinely replace all instances of {{ ndash}}, {{ spaced ndash}} and variations thereof with the HTML symbol entities, as the templates are a waste of computing cycles and slow the entire system down compared to using HTML entities directly."
"You didn't "fix" anything; indeed, you actually broke text flow. Evidently, the committee of two or three uninformed individuals who came to a "consensus" and formulated MOS:DASH were blissfully unaware that their rule causes dashes to sometimes end up at the beginning of a line, not at the end. A competent professional typesetter will never wrap an em dash or an en dash to the first position of a line in printed material. Unfortunately, many Web browsers do just that, and it makes text more difficult to read. Therefore, I will continue to ignore MOS:DASH and will precede em dashes and en dashes with a non-breaking space and follow them with a space. I will also continue to ignore the various templates that implement em dashes and en dashes in various screwy, unreliable ways."
2. Removal of inline templates from article leads (ledes). Editors have been requesting him to stop removing them for at least five years. The stated justification is "Putting inline templates in the lede results in run-together text or a puzzling syntax discontinuity, defeating the purpose of tool-tip previews." ( WP:POP)
Another editor requested he stop this in 2014: "I guess I think that the limitations of Navigation popups should not be imposed upon the rest of Wikipedia. Until and unless inline templates are proscribed at MOS:LEAD, they are permissible and shouldn't be removed." This request has been ignored.
3. Changing the first letter case in templates such as {{ reflist}} to {{ Reflist}}. When told this is unnecessary and not productive, they have responded "using lowercase is lazy". I personally always use lowercase because it is easier to read. (I recall a study that stated the greater variation between lowercase letters makes them easier for the humans to distinguish).
4: Bypassing redirects:
This is a request from 2.5 years ago to stop bypassing redirects which is still being ignored:
Hello. In our recent interaction on my talk page, here, I pointed you to the guideline WP:NOTBROKEN and asked that you read it and stop piping links for the sole purpose of bypassing redirects, per that guideline which represents a community consensus. You have not responded, but you continue to make such edits, as seen here (Second World War). Is there a reason you refuse to comply with a Wikipedia editing guideline?
This is their position:
"As for redirects, If I feel up to it, I fix them as I come across them, incidental to other copy-editing. In many cases the links are broken, because the redirects are put there as a work-around for improper terminology, capitalization, punctuation, spelling, or accessibility; when these issues are fixed, the link no longer references a redirect. Sometimes I remove links to redirects entirely, because they constitute overlinking. I am aware of the "policy", but it has become evident to me that some policy-making groups at Wikipedia are working at cross-purposes, i.e., "the left hand not knowing what the right hand is doing". On the one hand, after moving an article, they want us to fix up links in other articles that reference the moved article, but on the other hand we're told that redirects are "not broken". Which is it? It can't be both. Moreover, we're supposed to believe that redirects "don't cost anything", but only someone who doesn't understand how computers work at the hardware level would make such a claim. Finally, for logged-in users of standards-compliant browsers, Wikipedia supports navigation popups. It's a useful feature that redirects partially break, and the WP:NOTBROKEN policy may have been strongly influenced by persons unaware of this feature or insistent on continuing to use their favorite non-compliant browser."
"Redirects are ugly and cause problems for people such as I who make use of tooltip previews while reading articles. I wish editors like you would find more productive things to do, notwithstanding bureaucratic nonsense like not broken, which is usually written in a vacuum with no knowledge of how Internet resources are most effectively used."
6: General attitude about the MOS
"@ Chris the speller: — Ah, more Wikipedia make-it-up-as-you-go rules of grammar and punctuation. This wiki's Style Guide is gradually devolving into illiteracy, as such rules are promulgated by minuscule groups of editors who somehow avoided taking English writing classes in high school or college."
Well, I suppose the only place to take this is WP:AIN. I expect that doing so will result in walls of text there. I took a look at their talk page for prior similar issues and found many going back more than five years. There are no archives, so one must go through the page history to find deleted discussions.
The talkpage documents a history of ignoring consensus when the editor disagrees with a policy/guideline, shows a disdain for established WP procedure for determining consensus, and a general acerbic attitude when questioned.
The following are excerpts from the talk page. For brevity, I have quoted the editors responses on a variety of subjects.
1. Changing dashes:
"Professional typesetters don't do it that way, and the MOS:DASH decision by a tiny committee of four or five didn't take into account how Web browsers work"
"The WP:MoS article you cite was written in a vacuum by individuals who apparently have no idea how Web browsers work and don't know (or care to know) that HTML is for content control, not formatting control. HTML was never intended to be a desktop publishing tool. In my experience since 2004, trying to get such misconceptions corrected in Wikipedia is like trying to empty the ocean with a teaspoon, i.e., a useless endeavour. I use a script to routinely replace all instances of {{ ndash}}, {{ spaced ndash}} and variations thereof with the HTML symbol entities, as the templates are a waste of computing cycles and slow the entire system down compared to using HTML entities directly."
"You didn't "fix" anything; indeed, you actually broke text flow. Evidently, the committee of two or three uninformed individuals who came to a "consensus" and formulated MOS:DASH were blissfully unaware that their rule causes dashes to sometimes end up at the beginning of a line, not at the end. A competent professional typesetter will never wrap an em dash or an en dash to the first position of a line in printed material. Unfortunately, many Web browsers do just that, and it makes text more difficult to read. Therefore, I will continue to ignore MOS:DASH and will precede em dashes and en dashes with a non-breaking space and follow them with a space. I will also continue to ignore the various templates that implement em dashes and en dashes in various screwy, unreliable ways."
2. Removal of inline templates from article leads (ledes). Editors have been requesting him to stop removing them for at least five years. The stated justification is "Putting inline templates in the lede results in run-together text or a puzzling syntax discontinuity, defeating the purpose of tool-tip previews." ( WP:POP)
Another editor requested he stop this in 2014: "I guess I think that the limitations of Navigation popups should not be imposed upon the rest of Wikipedia. Until and unless inline templates are proscribed at MOS:LEAD, they are permissible and shouldn't be removed." This request has been ignored.
3. Changing the first letter case in templates such as {{ reflist}} to {{ Reflist}}. When told this is unnecessary and not productive, they have responded "using lowercase is lazy". I personally always use lowercase because it is easier to read. (I recall a study that stated the greater variation between lowercase letters makes them easier for the humans to distinguish).
4: Bypassing redirects:
This is a request from 2.5 years ago to stop bypassing redirects which is still being ignored:
Hello. In our recent interaction on my talk page, here, I pointed you to the guideline WP:NOTBROKEN and asked that you read it and stop piping links for the sole purpose of bypassing redirects, per that guideline which represents a community consensus. You have not responded, but you continue to make such edits, as seen here (Second World War). Is there a reason you refuse to comply with a Wikipedia editing guideline?
This is their position:
"As for redirects, If I feel up to it, I fix them as I come across them, incidental to other copy-editing. In many cases the links are broken, because the redirects are put there as a work-around for improper terminology, capitalization, punctuation, spelling, or accessibility; when these issues are fixed, the link no longer references a redirect. Sometimes I remove links to redirects entirely, because they constitute overlinking. I am aware of the "policy", but it has become evident to me that some policy-making groups at Wikipedia are working at cross-purposes, i.e., "the left hand not knowing what the right hand is doing". On the one hand, after moving an article, they want us to fix up links in other articles that reference the moved article, but on the other hand we're told that redirects are "not broken". Which is it? It can't be both. Moreover, we're supposed to believe that redirects "don't cost anything", but only someone who doesn't understand how computers work at the hardware level would make such a claim. Finally, for logged-in users of standards-compliant browsers, Wikipedia supports navigation popups. It's a useful feature that redirects partially break, and the WP:NOTBROKEN policy may have been strongly influenced by persons unaware of this feature or insistent on continuing to use their favorite non-compliant browser."
"Redirects are ugly and cause problems for people such as I who make use of tooltip previews while reading articles. I wish editors like you would find more productive things to do, notwithstanding bureaucratic nonsense like not broken, which is usually written in a vacuum with no knowledge of how Internet resources are most effectively used."
6: General attitude about the MOS
"@ Chris the speller: — Ah, more Wikipedia make-it-up-as-you-go rules of grammar and punctuation. This wiki's Style Guide is gradually devolving into illiteracy, as such rules are promulgated by minuscule groups of editors who somehow avoided taking English writing classes in high school or college."