Enabling notes near the end of the unit's implementation shows (unactionable) notes from Generics.Collections that should stay hidden

This report is a follow-up after #40222 (closed) , where @PascalDragon fixed a number of not useful notes/warnings being generated each time one specializes a TDictionary from Generics.Collections. Unfortunately, one can "restore" the unwanted notes, by using {$notes on} in the unit specializing the dictionary.

See the testcase: generics_dictionary_castle_loc.pas

$ fpc generics_dictionary_castle_loc.pas 
Free Pascal Compiler version 3.3.1-17294-gf417c87ec8-dirty [2025/01/12] for x86_64
Copyright (c) 1993-2025 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling generics_dictionary_castle_loc.pas
generics.collections.pas(158,52) Note: Private type "TCustomPointersEnumerator<GENERICS_DICTIONARY_CASTLE_LOC.TOnLocalizationUpdatedEvent,GENERICS_DICTIONARY_CASTLE_LOC.TCustomList$1$crcC74D932F_crc1CEAE787.PT>.T" never used
generics.collections.pas(158,52) Note: Private type "TCustomPointersEnumerator<GENERICS_DICTIONARY_CASTLE_LOC.TOnUpdateLocalizationEvent,GENERICS_DICTIONARY_CASTLE_LOC.TCustomList$1$crc276802A5_crc1CEAE787.PT>.T" never used
generics.collections.pas(158,52) Note: Private type "TCustomPointersEnumerator<SYSTEM.AnsiString,GENERICS_DICTIONARY_CASTLE_LOC.TCustomList$1$crc8D68C026_crc1CEAE787.PT>.T" never used
generics.collections.pas(158,52) Note: Private type "TCustomPointersEnumerator<GENERICS_DICTIONARY_CASTLE_LOC.TPair<SYSTEM.AnsiString,SYSTEM.AnsiString>,GENERICS_DICTIONARY_CASTLE_LOC.TCustomList$1$crc09D74DF2_crc1CEAE787.PT>.T" never used
generics.collections.pas(158,52) Note: Private type "TCustomPointersEnumerator<GENERICS_DICTIONARY_CASTLE_LOC.TFileLoaderAction,GENERICS_DICTIONARY_CASTLE_LOC.TCustomList$1$crc902E64DC_crc1CEAE787.PT>.T" never used
generics.collections.pas(158,52) Note: Private type "TCustomPointersEnumerator<GENERICS_DICTIONARY_CASTLE_LOC.TPair<SYSTEM.AnsiString,GENERICS_DICTIONARY_CASTLE_LOC.TFileLoaderAction>,GENERICS_DICTIONARY_CASTLE_LOC.TCustomList$1$crc4039751B_crc1CEAE787.PT>.T" never used
generics.collections.pas(158,52) Note: Private type "TCustomPointersEnumerator<GENERICS_DICTIONARY_CASTLE_LOC.TPair<GENERICS_DICTIONARY_CASTLE_LOC.TOnUpdateLocalizationEvent,SYSTEM.AnsiString>,GENERICS_DICTIONARY_CASTLE_LOC.TCustomList$1$crc91781ABA_crc1CEAE787.PT>.T" never used
44 lines compiled, 0.8 sec
7 note(s) issued

Tested now with FPC from the main branch, commit f417c87e , on Linux/x86_64.

Using {$NOTES ON} at the end of implementation of this unit seems to mistakenly reenable notes from generics.collections.pas.

I realize why this happens (this is where generics.collections.pas code actually gets specialized), but it's still surprising for developer. Someone used {$notes xxx} to influence notes generated by this unit (generics_dictionary_castle_loc), not notes from Generics.Collection specialization (and the specialize xxxx definitions are way earlier in this unit, {$notes...} are later).

Ideally, when the "specialization" code gets compiled, the verbosity (what warnings/notes are emitted) is influenced by the unit that defines the generic, not by the unit that specializes it. Or, as alternative, the verbosity active when we make specialize xxxx definition may make sense. It seems that now "whatever happens to be active when compiling end. of this unit" influences notes from Generics.Collection.

With the attached testcase generics_dictionary_castle_loc.pas, even compillimg with fpc -vn- ... makes 7 warnings from generics.collections.pas, since the {$notes on} reenable them.