Existe uma ferramenta regex seguindo apenas BRE e gerando erros quando indefinida?

POSIX define alguns caracteres, conhecidos como metacaracteres ou "caracteres especiais", que possuem significados não literais quando usados ​​em uma regexp, por exemplo, .corresponde a qualquer caractere. POSIX também define o que acontece quando você coloca uma barra invertida \antes de tal metacaractere, ou seja, ela se torna literal e corresponde a um caractere \.literal ..

Caracteres que não são tais metachares, por exemplo s(ou +em um BRE), são conhecidos como "caracteres comuns". O que o POSIX diz sobre caracteres comuns é o seguinte (ênfase minha):

9.3.2 Caracteres Comuns BRE

Um caractere comum é um BRE que corresponde a si mesmo: qualquer caractere no conjunto de caracteres suportado, exceto os caracteres especiais BRE listados em Caracteres Especiais BRE .

A interpretação de um caractere comum precedido por um sem escape ( '\' ) é indefinida , exceto para:

• Os caracteres ')', '(', '{' e '}'
• Os dígitos de 1 a 9 inclusive (consulte BREs que correspondem a vários caracteres )
• Um caractere dentro de uma expressão entre colchetes

ou seja, NÃO define especificamente o que acontece quando você coloca um \na frente de um caractere comum (exceto os poucos mencionados acima), e é por isso que as ferramentas podem definir \so mesmo significado [[:space:]] daquela ferramenta e ainda estar em conformidade com o padrão POSIX, já que qualquer ferramenta pode faça o que quiser com a entrada, de forma que o POSIX não defina como lidar com essa entrada.

A respeito de:

Existe uma ferramenta regex seguindo exatamente o BRE?

A maioria (todas?) grepE sedas implementações o fazem por padrão, mas uma ferramenta que implementa SOMENTE os comportamentos definidos pelo POSIX, como eu acho que você espera, simplesmente não pode existir porque o POSIX deliberadamente não define tudo (o POSIX descreve a funcionalidade comum que a maioria das ferramentas tem na maioria das situações, não dita como todas as ferramentas devem se comportar em todas as situações) e, portanto, quem está implementando qualquer versão de qualquer ferramenta tem que tomar sua própria decisão sobre o que fazer quando essa ferramenta encontrar alguma entrada cujo manuseio é não definido pelo POSIX - implemente algumas funcionalidades que eles acham que serão úteis, trate-as como caracteres literais, imprima uma mensagem de aviso, apague todos os seus arquivos, corrompa seu disco rígido ou qualquer outra coisa que acharem adequada. Contanto que implementem a funcionalidade definida pelo POSIX, essa ferramenta será compatível com POSIX, independentemente do que faça nos casos indefinidos.

Considere que existe um padrão para carros que diz “quando o motorista vira o volante para a direita, o carro vira para a direita”. Espera-se que um fabricante de automóveis cumpra esse requisito. O padrão provavelmente não define o que acontece se você puxar o volante em sua direção, então se a Nissan decidir que se você fizer isso em um Maxima 2015, o carro decolará e começará a voar ou se comprimirá em um pequeno cubo, isso ainda é compatível com o padrão. Da mesma forma, o POSIX define o que ., se \.significa, mas o POSIX não define o que \ssignifica e, portanto, o GNU pode definir \scomo equivalente [[:space:]]ou o que quiser e ainda ser compatível com POSIX.

Portanto, se você deseja um regexp que se comporte da mesma forma em todas as versões de uma ferramenta, como grepnas formas definidas pelo POSIX, apenas não escreva um regexp que dependa de um comportamento indefinido pelo POSIX. Isso inclui não escrever \+em BRE e não escrever \sem BRE ou ERE, e tudo o que grepvocê estiver usando estará em conformidade com o padrão POSIX aplicável ao processar esse regexp.

Regexps POSIX, BREs e EREs, são definidos no padrão POSIX , não na página de manual de qualquer ferramenta e definitivamente não em regex101.com, onde AFAIK não tem uma opção para lidar com BREs ou EREs POSIX.

Em relação à sugestão nos comentários para definir POSIXLY_CORRECT: POSIXLY_CORRECTaplica-se apenas a ferramentas GNU, portanto não ajudaria com ferramentas BSD, etc., e o que faz varia de acordo com cada ferramenta, mesmo dentro do GNU, por exemplo, no GNU awk com POSIXLY_CORRECT defina-o reportará \scomo comportamento indefinido e o tratará apenas como um literal sem um regexp, enquanto no GNU grep tratará \s(e \+) da mesma maneira, esteja POSIXLY_CORRECT definido ou não. Por exemplo:

$ echo 'a b' | gawk '/a\sb/'
a b

$ echo 'a b' | grep 'a\sb'
a b

$ echo 'a b' | POSIXLY_CORRECT=1 gawk '/a\sb/'
gawk: cmd. line:1: warning: regexp escape sequence `\s' is not a known regexp operator

$ echo 'a b' | POSIXLY_CORRECT=1 grep 'a\sb'
a b

$ echo 'asb' | gawk '/a\sb/'
$

$ echo 'asb' | grep 'a\sb'
$

$ echo 'asb' | POSIXLY_CORRECT=1 gawk '/a\sb/'
gawk: cmd. line:1: warning: regexp escape sequence `\s' is not a known regexp operator
asb

$ echo 'asb' | POSIXLY_CORRECT=1 grep 'a\sb'
$