No, there's not really a clear correct answer. The original motivation behind this idea was to play nicely with error-recovery rules, but in practice there are several reasonable behaviors. One is to pass the character as a token (with itself for semantic value) and let the grammar handle punctuation by reference to literal characters. Another, which makes particular sense for things like regular expressions, is to pass everything not specifically recognized as "character" (i.e. a fixed semantic class with the character itself for a value). Yet a third approach is to consider the occurrence as a bug in the specification: this is a verifiable property of the DFA which can be noticed if there is a path from a root to the error state without passing through an accepting state.
No, there's not really a clear correct answer. The original motivation behind this idea was to play nicely with error-recovery rules, but in practice there are several reasonable behaviors. One is to pass the character as a token (with itself for semantic value) and let the grammar handle punctuation by reference to literal characters. Another, which makes particular sense for things like regular expressions, is to pass everything not specifically recognized as "character" (i.e. a fixed semantic class with the character itself for a value). Yet a third approach is to consider the occurrence as a bug in the specification: this is a verifiable property of the DFA which can be noticed if there is a path from a root to the error state without passing through an accepting state.