That said, I don't see my lisp coffee caring that much. Let expressions benefit from lining up. Most other code, though? Not sure it matters that much.

> Put that in a non-proportional font, and the asterisks on the first line probably won't line up with the rest.

So lose the redundant asterisks. They serve no purpose. They make the comment both harder to read and harder to write.

At any rate, while you might be technically correct, in practice, "PHP and Java coders should abandon this long-held convention used by hundreds of thousands of programmers and decades' worth of tooling in order to avoid unsightly alignment issues when using proportional fonts in editors" may be a hard sell. :)

You quickly learn not to care about that. So what if the asterisks in the first boilerplate line don't line up with the ones below? And which of those two asterisks should have lined up with the others?

It just doesn't matter. Everything in the meat of the comment still lines up just fine in a proportional font, just as it does in monospace.

> Now think of someone doing visual alignment of assignment operators in a block of code like you often see in Ruby

I gave up that coding style many years ago, even before I switched to proportional fonts. You end up doing stuff like this (making up a contrived example, and not in any particular programming language here):

  name                  = user.name
  age                   = user.age
  driver_license_number = dl_database(user).dl_number

Maybe it is because I am getting older and all that sideways visual scanning is not as pleasant as it used to be. Maybe it is because of the unnecessary commit diffs that this style produces.

Once I stopped doing this, I realized that the code would look fine in any font, mono or proportional.

> or any code following the indentation standard where you line up parameters in a multi-line function header with the character after the open parenthesis like you often see in Python.

It's worth noting that Black, by far the most popular Python formatter, eschews column alignment in favor of a purely indentation-based format. Python code formatted with Black is just as readable in a proportional font as in monospaced.

Here is a more extreme example from Rust, whose rustfmt tool used to rely heavily on the kind of column alignment you're talking about:

    let mut rewrites = try_opt!(subexpr_list.iter()
                                            .rev()
                                            .map(|e| {
                                                rewrite_chain_expr(e,
                                                                   total_span,
                                                                   context,
                                                                   max_width,
                                                                   indent)
                                            })
                                            .collect::<Option<Vec<_>>>());

    let mut rewrites = try_opt!(
        subexpr_list
            .iter()
            .rev()
            .map( |e| {
                rewrite_chain_expr( e, total_span, context, max_width, indent )
            })
            .collect::<Option<Vec<_>>>()
    );

> re-teach a generation or two of programmers that indenting with the tab character is good, actually

Bless you for that! This is another advantage of indentation-only formatting. It stops mattering whether you use tabs or spaces! The code will be just as readable in any font, monospaced or proportional, and it won't matter at all if one dev prefers to render tabs as two spaces and another likes four.

The key to all of this is to abandon the kind of column alignment that monospaced fonts make so tempting.

I do agree with your point about Lisp. Monospaced fonts are so heavily ingrained in that culture that I couldn't begin to imagine how to change it.