[algorithms] uses "Let $E$ ..." (using E as a meta-variable for an expression) pervasively.

@CaseyCarter, any opinion here?

IIRC [algorithms] inconsistently used both \tcode{E} and $E$ as expression placeholders before applying P0896. We chose to use the former as precedent for the placeholder in the CPO specifications. The change to use $E$ consistently throughout [algorithms] happened in San Diego when I was integrating all of the range algorithm specifications into the std flavors.

I have a mild preference for $E$ - whose slanted font makes it "clearly" a meta-syntactic variable - over e - which is itself valid syntax for a C++ expression - as a placeholder, but I'll agree that any consistent style would be an improvement over what's in the working draft right now.

The general idea for \tcode vs. (e.g.) math formatting is that the former could be valid source code, given the right environment, whereas the latter is used for meta-variables in other situations, such as "atomic operations" or similar. So, using $E$ in the [algorithms] section for stuff that looks like valid code snippets is questionable. However, using lowercase "e" for the CPO specification (in harmony with the core language section) might make sense.

Editorial meeting:

• Do we want a consistent capitalization convention for the core language part, for types vs. expressions.
• Do we want to apply this to the library part as well?
• What should the convention be?

Deferring.

Editorial meeting: Use math variables for everything, including types. \placeholder remains for exposition-only names and forming parts of an identifier. Range-based for: explain range/begin/end as exposition-only identifiers. Use $T$ primarily, possibly with index, for types. Additionally, use $U$, $V$ for types unrelated to $T$. Use $E$ for expressions, possibly with subscript.

See also #326, #3139.