I think, there is a bug in the implementation.
I played around with the example from Unexpected behavior of the GENERATED source file property and CMP0118 and must say that I am really confused about the result.
Foremost, I thought a call to get_source_file_property for the GENERATED property would no longer result in a NOTFOUND but a 0 instead.
However, I think I know where at least some of the confusion might come from.
I originally thought that there will only every be one instance of a cmSourceFile for a specific file-path. (And the unit-tests for CMP0118 that I implemented probably reflect that assumption.) But that seems not to be true!
This is how I think to have understood it now:
There is either only one instance per processed CMakeLists.txt, or a common instance only exists for the CMakeLists.txt file in which it was first created and all its sub-CMakeLists.txt files. (When trying to access the same file afterwards from a parent-CMakeLists.txt file a new instance will probably be created.)
In general, that should not be a problem, because if any instance of cmSourceFile for a specific file-path was marked as GENERATED, that information is stored in the cmGlobalGenerator. So, each instance only needs to check there. (Although some instances might check too early…)
However, the problem is that for checking the cmSourceFile instance needs to know its full-path, which therefore first needs to be resolved.
But trying to resolve the full-path for non-generated files might be wrong in that situation! (Especially, as the logic for resolving the full-path and supporting missing extensions etc. is quite hard to understand. Is all that really needed? Isn’t it already deprecated for quite some time now?)
Then again, generated files will (probably) always be constructed with a full path so that their full-path could be resolved immediately. (Is that correct @brad.king ?)
So, possibly the solution would be to extend the cmSourceFile::GetIsGenerated function to additionally check the global store (and therefore at least temporarily resolve the full-path).
I tried it and the GENERATED property was visible in more situations. However, that was only a quick and dirty test. (And the OLD behavior would possibly become even more like NEW than it became already through the original implementation.)