No, no prácticamente de todos modos. Una máquina de estado finito normalmente solo recuerda un dato: su estado actual.
Una aplicación típica de un FSM es el lexing o el análisis. Por ejemplo, cuando estamos haciendo lexing, es (normalmente) bastante fácil codificar las acciones para cada entrada posible en términos de un estado actual y el valor de la entrada.
Por ejemplo, podríamos tener un NÚMERO en el que estemos leyendo los dígitos de un número. Si el siguiente carácter que leemos es un dígito, nos quedamos en el estado NÚMERO. Si se trata de un espacio o una pestaña, devolveríamos los dígitos y luego avanzamos a algún estado de WHITE_SPACE, o algo en ese orden.
Ahora, es cierto que en un FSM típico (especialmente uno que está implementado en software) terminamos con partes y piezas que técnicamente no encajan bien con un FSM combinado con el FSM en sí. Por ejemplo, cuando estamos leyendo los dígitos de un número, con frecuencia va a guardar la posición del primer dígito, de modo que cuando llegue al final podrá calcular fácilmente el valor del número.
El FSM en sí mismo tiene algunas limitaciones, no tiene ningún mecanismo de conteo. Considere, por ejemplo, un lenguaje que usó "/ " para iniciar un comentario y " /" para finalizar un comentario. Su lexer probablemente tendría un estado COMENTARIO que ingresó cuando vio un token '/ '. En este momento no tiene forma (a menos que se agregue otro estado como COMMENT2) detectar otro "/ " y darse cuenta de que se trata de un comentario anidado. Más bien, en el estado de comentario, reconocerá que */
le dice que deje el estado de comentario, y cualquier otra cosa lo deja en el estado de comentario.
Como se mencionó, ciertamente podría incluir un estado COMMENT2 para un comentario anidado, y en ese caso, un estado COMMENT3, y así sucesivamente. En algún momento, sin embargo, se va a cansar de agregar más estados, y eso determinará la profundidad máxima de anidamiento que permite comentarios. Con alguna otra forma de analizador (es decir, no es una máquina de estado pura, sino algo que tiene algo de memoria que le permita contar), puede rastrear su profundidad de anidamiento directamente, de modo que permanezca en el estado COMENTARIO hasta que alcance un token de comentario cercano que equilibra el primero, por lo que su contador vuelve a 0 y deja el estado COMENTARIO.
Sin embargo, como dije, cuando agregas un contador como ese, lo que tienes ya no es realmente un FSM. Al mismo tiempo, está en realidad bastante cerca, específicamente, lo suficientemente cerca como para que pueda simular el contador simplemente agregando más estados.
Sin embargo, en un caso típico, cuando alguien habla de implementar un FSM en el software, lo mantendrá razonablemente "puro". En particular, el software reaccionará a la entrada actual basándose solo en el estado actual y el valor de la entrada en sí. Si la reacción depende de mucho de cualquier otra cosa, generalmente no lo llamarán una máquina de estado (al menos si saben de lo que están hablando).