Classic context menu not taken over for symbolic-link files — all rules ignored (Win11, v1.9.18)

[loliri]

Environment

• Nilesoft Shell 1.9.18 (64-bit)
• Windows 11 26200.8457 x64
• Language: zh-CN (system menu items localized)

Symptom

When Shift+right-clicking a symbolic link file (mklink NTFS symlink), the classic context menu is passed through completely unprocessed:

• no Shell custom items are added,
• no modify/remove/find rules apply,
• the stock classic menu is shown as-is.

Normal files in the same folder, same window are handled correctly (custom items, rules, theming all active). Only symlink-file selections fall back to the raw menu.

Reproduction

1. Create a symlink: mklink link.txt target.txt (elevated prompt)
2. Restart Explorer
3. Shift+right-click target.txt → Shell menu applied ✓
4. Shift+right-click link.txt → raw classic menu, Shell inactive ✗

Debug evidence

I verified with a probe rule that renames matching items:

modify(find='剪切' title="["+this.title+"]")

(剪切 = the localized "Cut" verb, present in both menus)

• Normal file: the rename hits → the rule pipeline runs.
• Symlink file: zero items matched → the rule engine never processes that menu build at all. This is not a per-rule matching problem; the menu bypasses Shell entirely.

Suspected area

From reading Selections.cpp, GetFileProperties requests FGAOF_DEF which includes SFGAO_STREAM | SFGAO_LINK, and the classification chain (Stream → IsFile, Folder → IsDir) looks like it should still classify a symlink file as PathType::File. So whatever drops the selection seems to happen earlier than classification (or on a different path entirely for SFGAO_LINK items).

Question

Is this known / intended? Is there any config-side workaround? Happy to run test builds if it helps pinpoint the bail-out.