Right, that's what I meant by
The difficulty with that is that the user could then not easily change a bit of the #context without a heap allocation. That may be acceptable, or it may not be. Also it'd still occupy quite a bunch of space in the binary. But yes, it's a possibility.
You're right, I missed that! Thanks for pointing it out 
I don't pretend to know a lot about efficient implementations; I'm still quite unfamiliar with Swift's inner workings compared to my knowledge of Objective-C. I'm approaching this from the POV of ergonomics and API design, and my own experience of getting annoyed at having to splat file: String = #file, line: Uint = #line, function: String = #function in lots of places and manually forwarding on 3 different parameters.
To come back to the original proposal… I do think it could be very nice to have #module as a compiler-provided value and am interested in seeing this proposal move forward because of that. However, I'm wary because we keep coming up with these values (you made a nice list of them) and I wish there was a nicer way to package them all up and make them more ergonomic in code.
Slight nitpick: you counted file twice I think, so the totals should be 13 words & 18 words.
Simply storing all the relevant info for every occurrence of #context might be too expensive in binary size, but could we trade binary size for performance of actually accessing properties on the context object by having a lookup table that exploits the nested nature of modules, files, lines and columns? In that case, unless I'm missing something, a single word parameter might suffice for passing the context.
If that turns out too slow, maybe a happy medium could be found (e.g. keep column and line in the context struct, the rest in the lookup table) that would provide the right level of convenience, performance and binary size for most users.
For people who are looking for this feature.
We now have #fileID which contains module name at first segment.
+1 to this proposal. Stumbled upon the post while searching how to do exactly this. I also concur with the OP that the #fileID hack is just that: useful, but ultimately a hack. While the value would be generated at compile time, it will require string processing at runtime to remove the extraneous information.
That's not so horrible for my immediate need, but I can totally see that, for situations such as logging, this would be undesired overhead.