Como regla general, no desea que la sintaxis léxica se propague en la gramática, porque es solo un detalle. Por ejemplo, un lexer para un lenguaje de programación de computadoras como C ciertamente reconocería números, pero generalmente no es apropiado producir HEXAS NUMÉRICAS y NÚMEROS DECIMALES, porque esto no es importante para la gramática.
Creo que lo que quiere son los tokens más abstractos que permiten su gramática para distinguir los casos de interés en relación con su propósito. Puedes mediar en esto por la confusión causada en una parte de la gramática, por las elecciones que puedes hacer en otras partes.
Si su objetivo es simplemente leer más allá de los valores de bandera, entonces de hecho no necesita distinguir entre ellos, y un TknFlag sin contenido asociado sería suficiente.
Si su objetivo es procesar los valores de indicador individualmente, necesita saber si obtuvo las indicaciones RESPONDIDAS y/o SUPRIMIDAS. Cómo están léxicamente deletreados es irrelevante; así que iría con su solución TknAnsweredFlag. Me gustaría tirar el TknSpace, porque en cualquier secuencia de banderas, debe haber espacios intermedios (tu especificación lo dice), así que trataría de eliminar usando cualquier maquinaria de supresión de espacio en blanco que ofrezcas Lexer.
En ocasiones, me encuentro con situaciones en las que hay docenas de esas cosas tipo bandera. Entonces tu gramática comienza a estar desordenada si tienes un token para cada uno. Si la gramática no necesita conocer banderas específicas, entonces debe tener un TknFlag con un valor de cadena asociado. Si la gramática necesita un pequeño subconjunto de las banderas para distinguir, pero la mayoría no lo está, entonces debe comprometerse: tener tokens individuales para esas banderas que importan a la gramática, y atrapar todo TknFlag con la cadena asociada para el resto .
En cuanto a la dificultad de tener dos interpretaciones diferentes: esta es una de esas concesiones. Si tienes ese problema, entonces tus tokens necesitan tener detalles suficientemente detallados en ambos lugares donde se necesitan en la gramática para que puedas discriminar. Si "\" es relevante como un token en algún otro lugar de la gramática, ciertamente podrías producir tanto TknBackSlash como TknAnswered. Sin embargo, si la forma en que se trata algo en una parte de la gramática es diferente de la otra, a menudo puede evitar esto utilizando un lector de modo controlado. Piense en los modos como una máquina de estados finitos, cada uno con un (sub) lexer asociado. Las transiciones entre modos se desencadenan mediante tokens que son señales (debe tener un token de FLAGS; es precisamente una señal de que está a punto de recoger los valores de indicador). En un modo, puede producir tokens que otros modos no producirían; por lo tanto, en un modo, puede producir "\" tokens, pero en su modo de bandera no sería necesario. El soporte de modo es bastante común en los lexers porque este problema es más común de lo que cabría esperar. Consulte la documentación de Flex para ver un ejemplo.
El hecho de que haga la pregunta muestra que está en el camino correcto para tomar una buena decisión. Necesitas equilibrar el objetivo de mantenimiento de minimizar tokens (¡técnicamente puedes analizar usando un token para carácter ASCII!) Con requisitos fundamentales para discriminar lo suficientemente bien para tus necesidades. Después de que haya creado una docena de gramáticas, esta compensación parecerá fácil, pero creo que las reglas generales que proporcioné son bastante buenas.