I strongly agree on the proposal of fixing this, but I'm a tentative -1 on the justifications for changing the behavior of #file:
However, a great deal of code already uses
#fileand would in practice probably never be converted to
I agree with this, but I'm curious what proportion of projects actually use #file explicitly? I would guess that the vast majority of apps only use it indirectly by calling assert() or some other error handling or logging function that captures it as a default argument.
This magic behavior of assertions in the standard lib is also the reason why developers are inadvertently including path info in their binaries - because they aren't calling #file explicitly they don't realize it's being called at all. Those that are using it explicitly are much more likely to realize what it does and what the implications are.
So it seems that much of the benefit of changing #file would also be achieved by adding a #filename alternative and then replacing all uses of #file with #filename within the stdlib. (You could also reach out to popular 3rd party frameworks that use #file and make sure they are aware they should switch).
The "other alternatives" section also doesn't seem very exhaustive. For example here is another option that seems viable:
Deprecating (not removing) #file and then replacing it with #filename and #filepath seems like a good solution because then everyone using #file would get a warning in their project and would be encouraged to make an explicit choice to switch to the behavior they actually want, but it would not be a source-breaking change.