\sb shadows LaTeX's built-in subscript alias, so \providecommand is a silent no-op (breaks \E, \Exp, \eExp, ... in PDF)

[d-morrison]

The bug

macros.qmd:7 defines

\providecommand{\sb}[1]{\mathopen{}\left[#1\right]\mathclose{}}

but \sb is already defined by LaTeX itself --- latex.ltx:15884 has
\let\sb=_, the plain-TeX-compatible alias for the subscript character. So
\providecommand is a silent no-op under pdflatex, and every use of
\sb{...} typesets as a subscript instead of square brackets.

Verified directly:

\documentclass{article}\usepackage{amsmath}
\providecommand{\sb}[1]{\mathopen{}\left[#1\right]\mathclose{}}
\begin{document}
\show\sb
$\mu_0^2 \sb{(1-\pi) + \pi}$
\end{document}

> \sb=subscript character _.
! Double subscript.

pdflatex exits 1. MathJax/KaTeX have no such built-in, so the macro works
as intended in the HTML profile --- which is why this has stayed invisible.

Reach

\sb is not a rarely-used helper. Grepping macros.qmd, the whole
expectation family routes through it:

• \E, \Ef, \Exp, \Expf, \Expfc (lines 248-252)
• \hE, \hExp, \hExpf (lines 236-238)
• \eE, \eExp, \eExpf (lines 681-683)
• \hessijalt (line 190), \thmADistMLE (line 548)

So \E{Y \mid X=x} expands to \operatorname{E}_{Y \mid X=x} in PDF output
rather than \operatorname{E}[Y \mid X=x], and any \sb whose argument
follows a superscript is a hard error.

In d-morrison/rme alone there are 103 direct \sb{...} uses across 37
files, plus every indirect use through the macros above.

Suggested fix

Rename the macro (e.g. \brackets, or reuse the existing \paren naming
convention as \brak), and keep \sb only if it is deliberately
\renewcommanded with a comment saying it shadows the LaTeX built-in.
\renewcommand would at least make the shadowing explicit and would not
silently no-op --- but it changes the meaning of a standard control
sequence, so a new name is safer.

Caveat worth checking before acting

The reproduction above is a minimal document, not the rme book build. If the
rme PDF profile has looked correct in practice, something in that pipeline
must be neutralizing \sb first, and that is worth confirming before a
rename. Either way the two forms disagree, and the HTML and PDF profiles
should not render the same source differently.

Found while driving d-morrison/rme#1138,
where a new \mu_0^2 \sb{...} broke the PDF build outright.

Filed by Claude Code (AI agent).

[d-morrison]

Retracting this issue --- the premise is wrong, and I did not check it against the real pipeline.

macros.qmd is included as document content, and Pandoc's latex_macros extension expands \providecommand/\def macros in math, in the reader. LaTeX therefore never receives \sb at all, so LaTeX's own \let\sb=_ is irrelevant.

Verified through the actual pipeline:

quarto render probe.qmd --to latex
# probe.tex:
# \[\mu_0^2 \mathopen{}\left[(1-\pi) + \pi\right]\mathclose{}\]
# \[\operatorname{E}\mathopen{}\left[A \mid B\right]\mathclose{}\]
# \[\mathop{\hat{\operatorname{E}}}\nolimits\mathopen{}\left[Y \mid X\right]\mathclose{}\]
pdflatex probe.tex   # exit 0, no errors

The macro expands exactly as intended, in both profiles. \E, \Exp, \eExp and the rest are fine.

What I actually verified was a hand-built harness that extracted $$...$$ blocks and fed them to pdflatex directly, bypassing Pandoc --- an artifact the book never builds. The \show\sb output and the ! Double subscript. error were both real, and both were about that harness rather than about this repo.

No change is needed here. Closing as not planned.

Posted by Claude Code (AI agent) --- not written by a human.