Windows Forwarded Events connector with Windows Security Events NRT rules

I'm facing exactly the same challenge.

I've set up a Windows Event Collector (WEC) that receives Windows events from our on-premises servers. This WEC is Azure Arc-enabled and has the Azure Monitor Agent (AMA) installed.

After configuring the Windows Forwarded Events via AMA data connector in Microsoft Sentinel, the events are ingested into the WindowsEvent table, which is the expected behavior.

However, while reading the documentation, I came across the following note:

Microsoft Sentinel analytics rules and solution content can be table-specific. Many built-in Windows Security Events rules, including some near-real-time rules, query SecurityEvent and don't match data stored only in WindowsEvent. If you need those rules without modification, use the Windows Security Events via AMA connector. Otherwise, adapt the rule queries to use WindowsEvent or supported ASIM parsers.

This suggests that the SecurityEvent table may be the preferred table for security-related events.
After reading this, I also enabled the Security Events via AMA connector in Sentinel to better understand how it works. However, my understanding is that this connector is primarily intended for scenarios where AMA is installed directly on each server, rather than using a Windows Event Collector that receives all events through the Forwarded Events channel.

After experimenting with both the Windows Forwarded Events and Security Events connectors, I came up with the following potential configuration:
For both connectors, I use the Forwarded Events channel as the data source.
My configuration is as follows:

For the Windows Forwarded Events via AMA connector, I created several Data Collection Rules (DCRs) to collect all Windows events that I want to ingest, excluding security events.
For the Security Events via AMA connector, I created a DCR that collects all security events from the Forwarded Events channel (ForwardedEvents!*[System[Channel='Security']])

I'm currently testing this in a proof-of-concept (POC) environment. With this configuration, all Windows events except security events are ingested into the WindowsEvent table, while all security events are ingested into the SecurityEvent table.

Although this appears to work, I'm not yet confident enough to implement it in our production environment.

Is anyone else using the same approach, and if so, have you encountered any issues or limitations?