Files with trailing dot (period, full stop) like “file 2020.01.01.” or directories cause a real mess when there are Linux and Windows machines within the share. (Discussed earlier at Unable to sync documents or files ending with period(.) symbol)
It seems that Linux sharing such a file somehow gets (or got) created on Windows, but they cannot be used (deleted, updated) after by “usual means”. It seems to be posisble to delete them by manual intervention; however Syncthing seems to fail deleting them. The mess starts when syncthing actually starts reading it back and redistribute them.
Problem:
We had a share with a such filename created a long time ago (possibly back then Syncthing wasn’t aware of the problem), and it was unmanageable at Windows. When we have realised that last week I tried to delete it on Linux. It has been deleted, also deletion distributed.
However since Windows cannot delete it the directory was still there, then syncthing finds it again at the next scan, it will reappear everywhere, even after some Windows user manually deleted their files, since other windows users still had the file. Then it may start to create conflicted files, but when the directory have trailing dot these files may will be created in the directory with the wrong name.
Suggestion:
I believe windows versions shall emit an error when someone tries to share such a file from Windows (and reject sharing it), and I would guess that Windows version does already reject receiving (creating) such files with the TailCharacterConflict trailing error, which is also a good way to handle it (or it shall it is doesn’t).
If it’s a valid concern feel free to create a real issue from it; if it’s not your comments about why are welcome. 
Whether it’s worth it to also try to filter this out on the local side, in order to avoid announcing it to other devices, I’m not sure.