Erin

I'm unclear what this nets you, can't you hook the functions (at the dispatch point) regardless of if MM:S is opting in to the newer interface? The path forward to...

What parsing failures have you run into that would have been recoverable?

This seems like something that would be nice to suppress - perhaps only when the stock itself is marked as deprecated? Otherwise there is no warning-free migration path for libraries.

Reopening this as (briefly) discussed on Discord - a PR would be much appreciated for this one and it sounds like it'll be quite a while otherwise.

This was an intentional change, pragmas are now file-scoped.

I like the syntax choices here (I kind of have to, it's exactly what I suggested in the issue 😄)

What sort of info are you after from it? I don't think any of the standard stuff could work with interpreter stacks, but they should already have relevant info available.

I believe this has always been the case for L4D2, it's related to the `RadioMenuClosesOnInvalidSlot` workaround: https://github.com/alliedmodders/sourcemod/blob/4e15a92984570aee8cb8438c8fd8bd24876342ca/gamedata/core.games/common.games.txt#L386-L399 https://github.com/alliedmodders/sourcemod/blob/4e15a92984570aee8cb8438c8fd8bd24876342ca/core/MenuStyle_Radio.cpp#L476-L484 The menu system does have it's own validity concept which it uses...