Pandoc: logical mappings for latex output

[brainchild0]

_See https://github.com/jgm/pandoc/issues/5879#issuecomment-632985223_.

---

Problem

Overview

LaTeX is among the most popular output targets in current use with Pandoc. Similar to other languages, such as Markdown and HTML, LaTeX is a semantic language. Its full power and flexibility derives from a document structure being expressed through abstract semantic elements, applied to physical style and layout rules defined separately.

Currently LaTeX output in Pandoc inconsistently employs semantic elements. For an abstract document element corresponding naturally to a macro native to LaTeX, Pandoc utilizes that macro. For other document elements, Pandoc instead generates a sequence of physical formatting instructions.

This inconsistency produces a challenge against the user directly and flexibly adding custom stylization to the various formatting features throughout a document.

Example

Consider the following short Markdown document featuring several kinds of formatting elements:

Do you *strongly* agree?

---

I **very strongly** agree.

Transforming to a LaTeX target gives the following result:

Do you \emph{strongly} agree?

\begin{center}\rule{0.5\linewidth}{0.5pt}\end{center}

I \textbf{very strongly} agree.

The first formatting feature is handled using the LaTeX command \emph, already available in the environment, to apply, as given by the definition of the command, appropriate physical attributes to text carrying the logical distinction of emphasis.

The further features, a thematic break and strong emphasis, are not handled analogously, but rather by direct insertion of physical formatting instructions.

Observations

For many uses, the current behavior is adequate. In the case of emphasis, for example, published documents largely follow a convention of a heavier font weight for strong emphasis. Even in such a simple case, however, several weaknesses immediately emerge. Many font families provide a multiplicity of font weights, beyond a normal and bold weight familiar for casual formatting, and often one versus another may be preferred aesthetically, depending on a particular context.

In contrast to \textit{}, the \emph{} macro provided natively by LaTeX, though many casually view it as essentially the same, enables a target document to employ arbitrary typesetting features as may be needed or preferred, whether such features are very similar to the default, such as utilizing an oblique font in preference to an italic one, or rather are very different. Further, as many experienced users are aware, the \emph{} macro offered natively has the particular feature of redefining itself within its own scope, such that it behaves differently in a nested context. Generally, text within a doubly-nested invocation of the macro has the same appearance as text entirely outside of it, though even this effect may depend on context, as the macro might be redefined as appropriate for certain environments. The \texti{} macro lacks such behavior, and adding it would have detrimental effects

Whereas some may view existing functionality as adequate, it is unable to support a comprehensive breadth of cases and concerns.

Objective

The author of a LaTeX document is able to define arbitrary command macros, such as one that might contain the style of a thematic break. Since Pandoc output is automatically generated, rather than written manually, the question of reliance on such macros is not obvious. In the automated case, the generator can conveniently copy verbatim a static sequence whenever needed, as it has done here. If the target environment does not provide a command that corresponds to some formatting feature in the Markdown source, and if the user never creates, reads, or edits the target LaTeX document, then some might conclude that the usefulness of macros is limited or none.

In the case of HTML output, style sheets currently provide the utility that the current proposal would provide for LaTeX output. Suppose a user wants to alter the appearance of thematic breaks throughout the document. For an HTML target, it is easy simply to apply a style-sheet rule to the hr elements, altering any property of the display. It is even possible, using the CSS content property, to employ a textual representation, rather than a graphical one, such as to mimic the practice in typewriter manuscripts of using a row of asterisks. Similarly, if the LaTeX output expresses these elements as macros, then the user may freely define or redefine the macro in whatever scope is desired for some effect.

Solution

Concept

Pandoc might allow more flexible stylization of LaTeX output by allowing the user to define a sequence for direct substitution, such that the custom sequence, not the default representation, is used to represent the element. Such an approach presents obstacles that are neither easy nor necessary to resolve.

A better approach may be simply to name a LaTeX command, to be called wherever a thematic break occurs, and to be defined in the document preamble.

The resulting LaTeX fragment might then appear as follows:

Do you \emph{strongly} agree?

\thematicbreak

I \strong{very strongly} agree.

The user can provide a custom definition of the commands, if desired, in the header. In fact, taking advantage of scoping rules, the user can impart context-dependent definitions on the command.

Similar solutions are possible for other logical document elements.

Macros and Environments

The following table summarizes the mapping of native Pandoc types to native LaTeX constructs and any further macros and environments that Pandoc must supply.

| Pandoc Type | Native Syntax, Macros, and Environments | Pandoc-supplied Macros and Environments |
| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
| CodeBlock | \begin{verbatim} \end{vebatim} | |
| BlockQuote | \begin{quote} \end{quote} | |
| OrderedList | \item | \begin[level]{orderedlist} \end{orderedlist} |
| BulletList | \item | \begin[level]{bulletlist} \end{bulletlist} |
| DefinitionList | \begin{description} \end{description} \item{term} | |
| Header | \chapter{} \section{} \subsection{} \subsubsection{} | \labeledpara{} \labeledsubpara{} |
| HorizontalRule | | \thematicbreak |
| Table | | \begin{abstracttable} \end{abstracttable} \begin{abstracttablerow} \end{abstracttablerow} |
| TableCell | | \begin{abstracttablecell} \end{abstracttablecell} |
| Emph | \emph{} | |
| Strong | | \strong{} |
| Strikeout | \sout{} | |
| Superscript | \textsuperscript{} | |
| Subscript | \textsubscript{} | |
| Quoted | ` ' `` '' | |
| Cite | | |
| Code | | \inlinecode{} |
| Link | \href{address}{} | |
| Image | | \image{address}{alttext} |
| Note | \footnote{} | |

Remarks

An added benefit of using commands for their logical meaning is that if the user wishes to assume LaTeX as the source format for ongoing document revision, the generated LaTeX source could much more easily serve as a starting point, compared to the LaTeX output currently being generated, because it much more closely resembles to how a human author would write a document. Some have further expressed the utility of being able to transform losslessly between LaTeX output and native Pandoc AST.

See Also

Issues #5880 and #1541.

[jgm]

See #1541 for a fully general proposal along these lines.
It's always a tradeoff between customizability and the desire to produce LaTeX fragments that are usable without special definitions.
In the case of thematic breaks, there is probably a good reason to define a macro and use it, but I know that some users have reacted negatively to that suggestion.

[brainchild0]

I looked at #1541 just now and I regret that I am not following you.

The purpose of the proposal is to improve the LaTeX writer so that the output (before processing by the engine) looks, rather than more like TeX, less like TeX and more like LaTeX.

Consider a document as such:

header-includes: \renewcommand{\emph}[1]{\textsc{#1}}
---

One *small* thing.

In the final output, the word small is displayed in small caps because it is how the \emph macro, which maps to the * tag from MarkDown, is redefined by the user.

Similarly, if the generated output used a macro for thematic break, and any other structural features not trivially mapping to basic, existing macros, then the user could optionally supply a new or modified definition, without being harmed by not giving one.

I cannot respond to users who have reacted negatively, without seeing their reactions, but I presently can think of no cost to the user other than a trivial performance penalty of resolving the macro, which would occur anyway for a similarly handwritten LaTeX document.

Mostly I think the cost would be in the design changes to the writer, but I would definitely view the result as a functional and structural improvement to the design.

[jgm]

The idea of #1541 is to define tex macros that exactly match the pandoc AST elements.
(Well, you could do the same thing with LaTeX macros -- that part isn't important, as the source documents could be essentially the same however it's implemented.) So, like what you're suggesting here with thematic break, but across the board.

The main cost to using a macro is that the LaTeX will fail to compile unless you've defined this custom macro. (More a problem with fragments than with standalone, as in the latter case we can simply supply the required macro definition.)

[brainchild0]

The main cost to using a macro is that the LaTeX will fail to compile unless you’ve defined this custom macro. (More a problem with fragments than with standalone, as in the latter case we can simply supply the required macro definition.)

The idea was for Pandoc to supply the definition that the user could override (or, potentially, to supply a definition only if the user hasn’t supplied one).

LaTeX fragments have no usefulness by themselves as input to an engine, only through inclusion into a complete document. The problem you identify arises only if the target document is not created by Pandoc, and does not otherwise contain the needed definitions.

The structure of a LaTeX document generally entails, in sequence, a class declaration, package importations, options setting, definitions of custom macros that represent specialized logical features of the document, and then finally, the document body. Such structure has limited tolerance for arbitrary mixing among fragments of different documents, as such fragments commonly refer to custom macros defined within the host document, or those added from imported packages. The same is how I see document fragments that Pandoc generates.

Specific uses might be considered and handled, but I would hope that the dubious assumption that any LaTeX fragment ought to fit readily in any LaTeX document is not an obstruction to the serious consideration of the overall idea.

[brainchild0]

Also a new realization to me is that currently strong emphasis maps to \textbf.

I thought it might be worth mentioning because some might consider a natural symmetry between regular and strong emphasis, such not being represented in the current form of LaTeX output. This disparity is arguably more compelling than one involving thematic breaks or similar document features.

$ pandoc -t latex <<< '*A* **B** ***C***'
\emph{A} \textbf{B} \textbf{\emph{C}}

[kysko]

The usual answer is to say this can be done at the level of filters/templates.
The proposition given would not prevent this flexibility, so that wouldn't affect my workflow; however, since the flexibility is itself a solution, one can ask what more it would give.

As for emphasis and strong... one can find old discussions and some newer on that subject, which has more to do with (la)tex than pandoc.

[jgm]

LaTeX fragments have no usefulness by themselves as input to an engine, only through inclusion into a complete document. The problem you identify arises only if the target document is not created by Pandoc, and does not otherwise contain the needed definitions.

Exactly. Lots of people do use pandoc this way.

[brainchild0]

Exactly. Lots of people do use pandoc this way.

I guess I am still trying to understand what this way means, because LaTeX fragments are usually written according to their target environment, particularly, the available macros and their meanings.

Are LaTeX fragments generated by Pandoc required to integrate into non-Pandoc LaTeX documents? I am having some difficulty thinking about this case in a completely general way. Any LaTeX document could compile but not provide results that are visually appealing or even useful. Thus a document merely compiling probably is not sufficient for the effect that some included fragment has integrated successfully.

Meanwhile, if Pandoc LaTeX is restricted by the requirement of being able to compile in some conceived lowest common denominator for a LaTeX environment, we might miss potentially useful features without genuinely protecting an actual use case.

So I guess it would be helpful to outline the specific cases that need to be supported.

[denismaier]

The memoir class has commands that could be used in that context: \plainbreak or \fancybreak. Of course, this is not a general solution, but maybe a start.

See page 99 in the memoir manual.

[alerque]

Tying Pandoc's output down to being used in a specific LaTeX document class is not a good idea. Many of us, myself included, use other classes for all our work — sometimes including inserting Pandoc generated fragments into custom templates where Pandoc does not handle the whole standalone document.

[denismaier]

Yes, I am totally aware of that. (I mainly use KOMA-Script classes, memoir only in some special cases.) That's why I wrote it's not a general solution.
But: Perhaps we can use that command anyway and if the class isn't memoir we'd have to define it.

[brainchild0]

Exactly. Lots of people do use pandoc this way.

Taking the case of fragments, four possibilities appear:

1. Pandoc-generated fragment in Pandoc-generated document.
2. Pandoc-generated fragment in non-Pandoc generated document.
3. Non-Pandoc generated fragment in Pandoc generated document.
4. Non-Pandoc-generated fragment in non-Pandoc generated document.

Which among these would you identify as cases that are currently working, that would break with the proposed changes, and that you would want to protect from breaking?

[brainchild0]

The usual answer is to say this can be done at the level of filters/templates.
The proposition given would not prevent this flexibility, so that wouldn't affect my workflow; however, since the flexibility is itself a solution, one can ask what more it would give.

Filters provide flexibility, but are less effective than native features at providing a broad range of users with reliable, stable, robust, portable, and accessible functionality.

Functionality that might seem central to the stated goals of the application are worth considering for inclusion within the application.

As for emphasis and strong... one can find old discussions and some newer on that subject, which has more to do with (la)tex than pandoc.

These discussions as you say revolve around LaTeX. Since LaTeX has no builtin support for strong emphasis, Pandoc must handle it in some way, which currently is with the literal interpolation of the boldface macro. As such, typesetting a document with strong emphasis with character attributes other than this default of boldface is infeasible. In contrast, regular emphasis is handled with the emphasis macro, which can easily be overridden. Support for both types of emphasis is already given in some sense. A benefit of the proposal is to make both types of emphasis supported in comparably flexible ways.

[brainchild0]

But: Perhaps we can use that command anyway and if the class isn't memoir we'd have to define it.

This suggestion could be considered if the overall feature were added, but I'm not aware of any way to apply it without this addition occurring independently.

[kysko]

Pandoc must handle [strong emphasis] in some way, which currently is with the literal interpolation of the boldface macro

which is the "traditional" way, the one that is most expected

As such, typesetting a document with strong emphasis with character attributes other than this default of boldface is infeasible

I don't understand. This is literally the first example given in the Lua filters guide.

(/edit: removed an inaccurate paragraph)

It's just seemed to me that one of the point of filters, especially the relatively recent lua embedded functionalities in pandoc, was to give users this kind of liberty at redefining how the document is handled by the writers, rather than asking the developers for such or such features.

[alerque]

@brainchild0 re this comment. Scenario 2 currently works for _most_ cases (not quite all, but enough that it's generally useful). Your proposal breaks those use cases. I don't see any compelling gains here that would justify that kind of breakage.

[brainchild0]

Pandoc must handle [strong emphasis] in some way, which currently is with the literal interpolation of the boldface macro

which is the "traditional" way, the one that is most expected

I would consider the characterization as _the single most common way_ as more accurate than "traditional" way. You may mean the same, but I hesitate to use any representation that connotes that the default typesetting is the only possibility or is more correct or desirable.

As such, typesetting a document with strong emphasis with character attributes other than this default of boldface is infeasible

I don't understand. This is literally the first example given in the Lua filters guide.

I think that this example is slightly misleading. From my investigation, small caps is the only element currently in the AST that is narrowly a character attribute rather than a semantic category. Typesetting concerns the full breadth of visual effects, including everything related to color, font, spacing, graphical transformations, and so on. LaTeX is a typesetting system and unlike Pandoc includes rich support for all these details and related operations.

It's just seemed to me that one of the point of filters, especially the relatively recent lua embedded functionalities in pandoc, was to give users this kind of liberty at redefining how the document is handled by the writers, rather than asking the developers for such or such features.

The "main point" might be an underdefined distinction. Conceptually, since filters operate on the AST, which is above all else a semantic representation of the document, the purpose of filters might be considered to be to modify the semantic structure of a document, . Reversing the order of the sections would an example a such a semantic change, though perhaps a very odd one.

If Pandoc blurs the boundary between semantic and literal features of the target format in a way users find important, then they could say that inserting literal output features is the "main point". The discrepancy has no objective resolution, but I would point to the semantic-oriented design of the system, and suggest that feature development follow at least from these antecedents.

But the core of your distinction aligns to the orthogonal axis of what is a user extension versus what is a core feature of the application. Usability and stability play as important a role in this assessment as possibility. Resources might not be available for development of certain features, but the mere possibility of having functionality from extensions by filters seems to me a poor reason not even to consider an application feature.

[brainchild0]

@brainchild0 re this comment. Scenario 2 currently works for _most_ cases (not quite all, but enough that it's generally useful). Your proposal breaks those use cases. I don't see any compelling gains here that would justify that kind of breakage.

Scenario Two: Pandoc-generated fragment in non-Pandoc generated document.

The simplest example I can develop breaks for this combination of elements.

$ latex -halt-on-error '\documentclass{article}\begin{document}' $(pandoc -t latex <<< '# Head') '\end{document}'
This is pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian) (preloaded format=latex)
 restricted \write18 enabled.
entering extended mode
LaTeX2e <2017-04-15>
Babel <3.18> and hyphenation patterns for 3 language(s) loaded.
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo)) (./article.aux)
! Undefined control sequence.
<*> ...class{article}\begin{document} \hypertarget
                                                  {head}{% \section{Head}\la...
No pages of output.
Transcript written on article.log.

I'm trying to move toward a process of understanding what functionality is considered necessary to preserve and how it can in fact be preserved.

[kysko]

I hesitate to use any representation that connotes that the default typesetting is the only possibility or is more correct or desirable

We might agree, but we must also think about the reader and its expectations/understanding of our expressions.

I think that this example is slightly misleading. From my investigation, small caps (...)

The point was that the first example given was to change the behavior of Strong, and that is not so "infeasable". That smallcaps were used is only a detail.
One could use RawInline to wrap the content in a latex command (see below); on a more complex level, one could walk the inlines and detect if there's another Strong element, and act accordingly for a more complex approach.

If Pandoc blurs the boundary between semantic and literal features of the target format (...)

If one takes your initial example, we could have a filter take the HorizontalRule block and replace it with a latex RawBlock to write \thematicbreak in the document, and also have a complementary "header include" consisting in the latex command definition (which could be inserted as metadata, or include files, all part of a package).
Similarly with Strong, "mapped" to e.g. a \strong command through RawInline.

So it's a question of where this does happen. You'd like it to happen at the core of pandoc, which is fine in itself, I'd even use it, don't get me wrong.
But what you see as a "poor reason", I rather see a modular approach where users can define these kind of things the way they want (such as the above "mappings"), if they want, without having to dig into Haskell, and let the "core" development concentrate on deeper matters that can't be conveniently covered by filters alone.

Of course, such a user extension might be considered so useful that it is "cooked" as a native feature in the main application. If the developers consider it is the case with your proposal, I'll be fine with it.
If not, however, you're still free to implement your proposal as a package of filters and templates. And I find that freedom a powerful feature of pandoc in itself.

[brainchild0]

Many of the core premises and themes in your comments are relevant and sound, but I have difficulty identifying a clear expression of your premises and how they lead directly and plainly to your conclusions. I'll respond to your comments, but we may have reached a point where further discussion is no longer exposing new insights or facts. I've emphasized key clauses that have a central relation to the areas of controversy.

---

I hesitate to use any representation that connotes that the default typesetting is the only possibility or is more correct or desirable

We might agree, but we must also think about the reader and its expectations/understanding of our expressions.

Again what is common and what is inevitable are being conflated. Choosing reasonable defaults is a separate matter from choosing a mechanism for overriding those defaults. Do you attach usefulness to the LaTeX emph? If so, why not ascribe comparable usefulness to comparable effects? Or would you prefer simply that everyone use textit?

Some fonts come in 12 weights. Which does the reader "expect" to represent strong emphasis? Is the answer the same in all contexts throughout a document? Sometimes emphasis is nested. What does the reader "expect" for this representation?

Have you considered all the general cases that might challenge a more rigid nucleus of expectations? Might it be wise to assess these expectations from a more flexible approach?

One could use RawInline to wrap the content in a latex command (see below); on a more complex level, one could walk the inlines and detect if there's another Strong element, and act accordingly for a more complex approach.

"Infeasible" is an elastic term, and I would accept that in isolation this term would not make my case compelling. But its invocation was intended in context, not in a vacuum. I have repeatedly pointed to a broader set of concerns, such as usability and stability, which are being sidestepped in this discussion. You may not enter this discussion with a feeling that such concerns are important or compelling, but I do, and I have found nothing in your comments that give me cause to reconsider those concerns or their strong relation to the proposed idea.

So it's a question of where this does happen. You'd like it to happen at the core of pandoc, which is fine in itself, I'd even use it, don't get me wrong.
But what you see as a "poor reason", I rather see a modular approach where users can define these kind of things the way they want (such as the above "mappings"), _if they want_, without having to dig into Haskell, and let the "core" development concentrate on deeper matters that can't be conveniently covered by filters alone.

What specifically is the overarching modular principle you are trying to preserve? A proposed principle that would be consistent with your conclusions is that _no software package should include any functionality that can be achieved outside that particular software package_. But such a principle is entirely absurd. Generally, projects identify a set of objectives and then implement features that realize those objectives.

What do you think should be the deeper matters that attract the interest of development efforts, and what core principle do you propose that supports these matters more so than others?

[kysko]

we may have reached a point where further discussion is no longer exposing new insights or facts

Indeed. ~The present message will be my last in this current discussion, at least for some time.~
/edit: I obviously didn't follow through that last "promise"!

---

Again what is common and what is inevitable are being conflated (...)

Going back to my earlier comment, I took care to put "traditional" in quotes, when referring to how pandoc renders strong emphasis currently. It was a small innocuous comment, but has now escalated out of proportions. I'll leave it at that, and refer people to the two StackOverflow links I gave previously.

Have you considered all the general cases (...) Might it be wise to assess these expectations from a more flexible approach?

I haven't, actually, and never pretended to.
As for nested emphasis, I quickly addressed the case, which you immediately quoted.

I have repeatedly pointed to a broader set of concerns, such as usability and stability, which are being sidestepped in this discussion.
You may not enter this discussion with a feeling that such concerns are important or compelling, but I do (...)

Not sidestepped, just not convinced that existing means have less usability or stability.

(...) and I have found nothing in your comments that give me cause to reconsider those concerns or their strong relation to the proposed idea.

And I'd be disappointed if you were so easily swayed.

What specifically is the overarching modular principle you are trying to preserve?

Trying to preserve? I've stated since my first post in this discussion that your proposition would not prevent the existing flexibility.

A proposed principle that would be consistent with your conclusions is that no software package should include any functionality that can be achieved outside that particular software package.

That's quite a manichean view of the discussion.
So let me say it again: if the developers consider your proposal useful and implement it, I'll be fine with it.

---

Do not think though that I consider what you say unimportant or uninteresting.

But I did notice there's not much "meat" to it, in crude terms, which is to say I haven't yet seen what those "logical mappings" would be, apart from the original post.

So, how about showing a more practical/concrete side of your proposition, at least what should be "mapped", and with which original definitions. Not the Haskell part of course, the LaTeX part. Doesn't have to be complete.

As stated above (not by me), some people might be reluctant on such changes, but maybe some actual details might pique their interest.

[brainchild0]

It was a small innocuous comment, but has now escalated out of proportions.

I haven't, actually, and never pretended to.

That's quite a manichean view of the discussion.

Maybe I overstepped the language in some cases. It was not my intention to misrepresent or to overreact. In the last case, I hoped it was understood, though perhaps it was not, that I was not seriously suggesting that you believe absurd premises, but rather employing a rhetorical device. The intention was to express my own difficulty extrapolating what might be the actual premises with which you are beginning.

But I did notice there's not much "meat" to it, in crude terms, which is to say I haven't yet seen what those "logical mappings" would be, apart from the original post.

To me the core concept seems straightforward, perhaps with most of the open questions oriented towards the best way to achieve it, especially given some concern about the possibility of breaking some important functionality. I am doubtful that making this change non-breaking is as difficult as some portray it, but I cannot make such a demonstration without a concrete representation of that important functionality.

As stated above (not by me), some people might be reluctant on such changes, but maybe some actual details might _pique_ their interest.

I agree, but the original post carried a good amount of detail, which anticipated some objections. At this point it is more reasonable for me to respond to further objections than to anticipate them. It think I answered what has already been put forward as well as possible given the content of those comments. I would fill any gaps if I am pointed to them.

So, how about showing a more practical/concrete side of your proposition, at least what should be "mapped", and with which original definitions. Not the Haskell part of course, the LaTeX part. Doesn't have to be complete.

In the same spirit as above, I'll answer questions, but without specific inquiries, I lack a sound means to ascertain what you think is still missing.

Not sidestepped, just not convinced that _existing means_ have less usability or stability.

I'm glad you do feel that usability or stability are relevant and important. If we both agree on these values, then the difference rests in what you might need to be convinced that the idea favors these objectives. Here might lie the foundation of a more fruitful discussion.

[kysko]

(well, well, here I am, breaking momentarily what I announced in the intro of my last post... I know, I know, this should/could go in the "mailing list"... ok, ok, just before the weekend...)

I hoped it was understood (...) but rather to employ a rhetorical device

No, it was not, but now is. Semantics (from my limited knowledge) go way beyond what is simply written, ultimately transcending what pandoc or such can capture or translate. Let's remember that.

I am doubtful that making this change non-breaking is as difficult as some portray it

I hope you don't think I portrayed it as so.
Any such changes that you proposed would (or should, in my opinion) be possible to be completely undone at the filter level... just as what you proposed could be also completely implemented at that level.

It is in that sense I say I'd be fine whatever the devs do with what you propose.

but I cannot make such a demonstration [non-breaking change] without a concrete representation of that important functionality

Which is why I proposed you make a concrete representation of that functionality!

(Hint: one concrete representation could be through filters! At least temporarily! After all, aren't filter manipulations some indirect way to do what can be done -- up to certain limits, I admit -- in the Haskell code? Yes, I know you know this is a trap... 😉 )

At this point it is more reasonable for me to respond to further objections than to anticipate them. (...)
I lack a sound means to ascertain what you think is still missing.

The title of your proposal is _"logical mappings for latex output"_ : the _"logical mappings"_ are what are missing!

At this point, the objections you'll get can be as theoretical as your proposal, leading to nebulous discussions without a concrete basis to start with.
But maybe you prefer it that way... This is your turf, your choice... signing out...

---

/Edit of an Edit (2020-05-06):
A few days ago, the OP has noted that he/she "heavily edited" the initial message which may "reveal some discrepancies" "through the entire discussion".
Presently, as I write this, the GitHub history of that message shows the addition of a table of "mappings" on 2020-05-05, which might then seem to contradict my above response where I say these are what were missing.
I wanted to clarify this detail since this was not clear in the OP's numerous edits made 6 months later.

[brainchild0]

The memoir class has commands that could be used in that context: \plainbreak or \fancybreak. Of course, this is not a general solution, but maybe a start.

It appears these macros have arguments whose values would be supplied by a user based on the desired customized style of the document. Since no values would have global appeal, perhaps it is best to leave the potential use of the macros as a feature of the document, not of the general solution. Nevertheless, availability only within a specific document class is no reason not to check for their availability dynamically, if a choice is made to use any such macro when available. Further, a customizable macro as proposed would give the user the flexibility to employ such a macro in any document as desired simply by redefining the specific macro representing the semantic item.

[brainchild0]

I had begun extensive revisions of the original request, largely in response to comments, but soon found that the ultimate form would be a much larger document, and would render obsolete most of the content of the previous discussion. As such, I instead have chosen to place the document in a new issue.

The document attempts to mitigate doubt, to the extent that I have been able to understand the concerns expressed in earlier comments.

If the new issue will provide a greater benefit than the current one, then I would find no reason to keep open the latter.

See #6394.

[mb21]

As such, I instead have chosen to place the document in a new issue.

See #6394.

okay, closing in favour of #6394 then