The way I transcribed the error reflects how it appeared. I've attached a screenshot of it now. (Should've done that to begin with.)
The first time this occurred, I had admittedly been testing my game (to what extent it can be described as such) in ScummVM. However by the time I posted my previous message I had already tried saving the file again under every possible scenario, including completely rebooting the OS. Surely, its file handles can't persist across reboots.
Your description of how WinAGI handles WORDS.TOK got me thinking, Linux handles files slightly differently vs. Windows, and that can sometimes cause bugs. ...The most well-known phenomenon would be files of different cases being treated as different, I seem to recall ScummVM's readme warning that under Linux some games (such as later Humongous games) would need to be renamed to all upper or lowercase in order to work... they had been shipping games with filenames like Pajama.HE0, PAJAMA.(a), and pajama.HE4... and every other combination imaginable... sometimes all at once. This is fine on Windows, but since on Linux PAJAMA and pajama look different, it wouldn't be able to find the files... I think that's been resolved by now and you can use the files as they are, though I'm not sure how.
In the case of WinAGI, I enabled debug output, and within the... over 500MB of text that gave me, I found a few references to a .tok capitalization:
0009:Call oleaut32.VarBstrCmp(01a91a64 L".tok",6265a600 L".agw",00000000,00030001) ret=6601b0e8
0009:Call ucrtbase.memcmp(01a91a64,6265a600,00000008) ret=6a35c9a0
0009:Ret ucrtbase.memcmp() retval=00000001 ret=6a35c9a0
0009:Ret oleaut32.VarBstrCmp() retval=00000002 ret=6601b0e8
0009:Call oleaut32.SysFreeString(01a9887c L".TOK") ret=660e60df
0009:Call ntdll.RtlSizeHeap(00110000,00000000,01a98878) ret=65232200
0009:Ret ntdll.RtlSizeHeap() retval=00000010 ret=65232200
0009:Ret oleaut32.SysFreeString() retval=00000000 ret=660e60df
0009:Call oleaut32.SysFreeString(01a91a64 L".tok") ret=660e60df
However, I couldn't find any corresponding references in the WinAGI source code.
My other thought is in how Linux handles file handle exclusivity... with a file open in a program, I can rename it or even delete it... can't do that on Windows. The program it was open in will act as if you hadn't done these things until you close the file, when the program will return to reality... after it's closed, the program will no longer be able to find the file if you try to reopen it. (And in the case of deleted files, the space the file occupies on the partition won't freed until the deleted file's been closed...) However, I can't think of how this would affect WinAGI.