根据你描述的现象，这确实是HarmonyOS Next 5.0.5版本（API 5.0.5）在三键导航监听上的一个已知问题。问题核心在于：当用户通过系统设置中的“三键导航”开关直接关闭时，应用层通过systemUI.navigationBar接口监听的状态变化事件未能正确触发，且通过getValue方法获取的状态值也未同步更新（可能仍返回开启状态的值，如1）。

问题分析：

1. 现象一致性：你在6.0版本设备上监听和获取均正常，这证实了当前文档的适配逻辑本身是正确的。问题仅特定于5.0.5版本。
2. 触发路径差异：你补充的关键信息——“通过打开悬浮导航来关闭三键导航能收到变化，但直接开关三键导航则不能”——进一步定位了问题发生的具体场景。这表明在5.0.5版本中，系统设置界面直接操作“三键导航”开关时，状态变更的通知机制存在漏洞，未能正确下发到应用监听器。

结论与应对：

这是一个系统底层在特定版本（5.0.5）对特定操作路径（直接开关三键导航）的事件通知机制存在的缺陷。由于是系统层级的Bug，在应用代码层面无法通过修改监听方式来规避或修复。

建议的临时核查方案：

对于运行在5.0.5版本上的应用，如果需要确保获取到最准确的三键导航开关状态，不能完全依赖单次监听事件或getValue的即时返回值。可以考虑增加一个容错机制：在关键逻辑依赖导航栏状态时（例如布局调整），除了响应监听事件，可以尝试结合其他相关系统事件（如应用回到前台onForeground）或进行短时延迟后再次主动调用getValue进行状态确认，以降低因事件未通知而状态不同步的风险。但请注意，这并不能从根本上保证100%实时性。

该问题在后续的HarmonyOS版本（如你测试的6.0）中已被修复。