CL 19622 inserted a text/scanner prefix at the beginning of any error printed to standard error.

This was motivated by confusion on #14166 about where some output was coming from. But the fix seems to me a regression, at least in the case where the scanner knows the file name. If, say, a program like a compiler or assembler were using text/scanner to lex its input and using text/scanner's default error implementation (that is, not providing a custom error implementation), then previously an invocation reporting a lexical problem might look like:

$ myprogram foo.txt
foo.txt:10:12: illegal hexadecimal number
$

Now it looks like:

$ myprogram foo.txt
text/scanner: foo.txt:10:12: illegal hexadecimal number
$

I do understand that if the file name is not known, then this is confusing, as in #14166:

$ myprogram < foo.txt
10:12: illegal hexadecimal number
$

But perhaps the fix, if one must be made, would be to replace an empty file name with a pseudo-name like <input>, as in:

$ myprogram < foo.txt
<input>:10:12: illegal hexadecimal number
$

I think this form makes it clearer that 10:12 is an input position, without exposing an implementation detail (namely the use of text/scanner).

The critical point here is that the errors printed by text/scanner are expected by the users of text/scanner; they are a natural part of the operation of scanning input.

In contrast, in the rare case where a package prints a message to standard error to report an problem such as a consistency violation, that message is not unexpected and so a prefix is entirely appropriate.

I suggest text/scanner be changed to remove the new text/scanner prefix and possibly print <input> instead of an empty file name at the beginning of an error message (but not in Position.String, which might have other users).