How are code fence info strings considered? The spec avoids requiring functionality for them, but virtually all uses of info strings treat the first word as the language of the code sample, as mentioned in the spec. That language is either parsed like a file extension (e.g. md) or a language name (e.g. rust), introducing something very similar to English keywords. The generic directive proposal is in a similar but rougher spot (that you commented on in 2015), where the spec can avoid predefining any keywords but also where virtually all uses of this functionality will imply a language.
Perhaps a symbolic variant of the generic directive proposal would be appropriate for admonitions, or the existing generic directive proposal can work if emojis or other symbolic/pictographic Unicode character sequences are the keywords? E.g.
:: ℹ️ [This is my leaf note block content, with directive name `\u2139\ufe0f`.]
::: ℹ️ [My container note block title]
This is my container note block content, with directive name `\u2139\ufe0f`.
:::
Your admonition emoji proposal from earlier works well here for directive names. Note that those using an emoji shortcode extension could also support shortcode syntax in directive names, at least for leaf block & container block directives, unless they desire to make spaces mandatory for leaf & container block directives so the inline syntax :name[content]{key=val} used with a shortcode (e.g. ::information_source:[Inline directive content]) is unambiguous against the leaf block syntax :: name [content] {key=val} (e.g. :: :information_source: [Leaf block directive content]), and the latter is unambiguous against the container block syntax ::: name [inline-content] {key=val} (e.g. ::: :information_source: [Leaf block directive inline content]).