Uma coisa que ninguém mencionou ainda, então vou mencionar: o desejo de aninhar comentários geralmente indica que o programador está fazendo errado.
Primeiro, vamos concordar que o único momento em que "aninhamento" ou "não aninhamento" é visível para o programador é quando ele escreve algo estruturalmente assim:
do_something();
/* comment /* nested comment */ more comment */
do_something_else();
Agora, quando isso acontece na prática? Certamente o programador não escreverá comentários aninhados que literalmente se parecem com o trecho acima! Não, na prática, quando aninhamos comentários (ou desejamos poder aninhá-los), é porque queremos escrever algo como isto:
do_something(); /* do a thing */
/* [ajo] 2017-12-03 this turned out to be unnecessary
do_something_else(); /* do another thing */
*/
E isso é ruim. Este não é um padrão que nós (como designers de linguagem) queremos incentivar! A maneira correta de escrever o trecho acima é:
do_something(); /* do a thing */
Esse código "errado", esse início falso ou o que quer que fosse, não pertence à base de código. Pertence, na melhor das hipóteses, ao histórico de controle de origem. Idealmente, você nunca escreveria o código errado para começar, certo? E se o código errado estava servindo a um propósito lá, alertando os mantenedores para não restabelecê-lo por algum motivo, bem, provavelmente é um trabalho para um comentário de código intencional e bem escrito. Tentar expressar "não faça X" apenas deixando um código antigo que faça X, mas comentado, não é a maneira mais legível ou eficaz de impedir as pessoas de fazerem X.
Tudo isso se resume a uma regra simples que você já deve ter ouvido antes: não comente o código. (Buscando essa frase vai aparecer um monte de opiniões em acordo .)
Antes que você pergunte: sim, linguagens como C, C # e C ++ já dar o programador outra ferramenta para "comment out" grandes blocos de código: #if 0. Mas essa é apenas uma aplicação específica do pré-processador C, que é uma ferramenta grande e útil por si só. Na verdade, seria extremamente difícil e especial para um idioma suportar compilação condicional com #ife ainda não suporte #if 0.
Portanto, estabelecemos que comentários aninhados são relevantes apenas quando o programador está comentando o código; e estabelecemos (por consenso de muitos programadores experientes) que comentar código é uma coisa ruim.
Para concluir o silogismo, devemos aceitar que os designers de linguagem tenham interesse em promover as Coisas Boas e em desencorajar as Coisas Ruas (assumindo que tudo o resto é igual).
No caso de comentários aninhados, tudo o resto é igual - você pode ignorar com segurança as respostas com baixa votação que afirmam que a análise aninhada de /*alguma forma seria "difícil" para o analisador. (Aninhado /*não é mais difícil do que aninhado (, que quase todos os analisadores do mundo já precisam manipular.)
Sendo assim, tudo o resto é igual, um designer de linguagem deve facilitar o agrupamento de comentários (ou seja, comentar o código) ou difícil? Lembre-se de que comentar código é uma coisa ruim.
QED
Nota de rodapé. Observe que, se você não permitir comentários aninhados,
hello /* foo*/bar.txt */ world
é um "comentário" enganoso - é equivalente a
hello bar.txt */ world
(o que provavelmente é um erro de sintaxe). Mas se você fazer permitir comentários aninhados, em seguida,
hello /* foo/*.txt */ world
é um "comentário" enganoso - é equivalente a
hello
mas deixa o comentário aberto até o final do arquivo (que novamente é quase certamente um erro de sintaxe). Portanto, nenhum dos dois lados é particularmente menos propenso a erros de sintaxe não intencionais. A única diferença está em como eles lidam com o antipadrão intencional do código comentado.