The interpretation is only partially correct. The key points from the documentation are:

1. VNetLocalRouteOverrideCriteria is only relevant when all of the following are true:
   • A static route is configured on the Virtual WAN Virtual Network connection.
   • The spoke VNet address space is a subnet of that static route prefix.
   • The decision is about whether traffic to IPs inside that spoke VNet prefix should follow the static route’s next hop or bypass it.
2. What the setting actually does (no routing intent yet):
   • Disabled (vnetLocalRouteOverrideCriteria = "contains", portal: Bypass = No):
     • All traffic that matches the static route’s prefix is sent to the static route’s next hop, including traffic to IPs inside the spoke VNet itself.
     • This is what causes the “hairpin” behavior to an NVA/load balancer in the examples.
   • Enabled (vnetLocalRouteOverrideCriteria = "equals", portal: Bypass = Yes):
     • Traffic to IPs inside the spoke VNet prefix bypasses the static route and goes directly to the target VM.
     • Traffic to other prefixes that are still within the static route’s range (for example, indirect spokes) continues to use the static route next hop.
   This behavior is illustrated in the “Bypass Next Hop IP for workloads within this VNet” section and diagrams.
3. Interaction with routing intent and “Propagate static route” The context explicitly states two important overrides:
   • When routing intent is applied and Propagate static route is enabled on the VNet connection, the bypass setting is ignored:
     • “For deployments where static routes are specified on a virtual network connection with Propagate static route enabled, the bypass next hop IP behavior is ignored when routing intent is applied.”
     • In this case, the effective behavior is treated as bypass/equals for traffic to the spoke VNet itself.
   • When a 0.0.0.0/0 static route is configured on the VNet connection, the bypass setting is also ignored and treated as bypass/equals:
     • “When a 0.0.0.0/0 route is configured as a static route on a Virtual Network connection, the bypass next hop setting that is configured on the Virtual Network connection is ignored and considered to be set to bypass/equals.”
   In both cases, traffic destined for IPs inside the spoke VNet is inspected by the security appliance in the hub and then routed directly to the destination IP in the spoke, bypassing the next hop IP configured in the static route.
4. Implications for the two scenarios in the question

   1. When VNetLocalRouteOverrideCriteria = Yes (Bypass enabled)

   From the base feature description (without routing intent overrides):
   • Traffic to IPs inside the spoke VNet prefix bypasses the static route next hop and goes directly to the VM.
   • Traffic to other prefixes within the static route range still uses the static route next hop.
   However, with routing intent + Propagate static route enabled, the documentation states that the bypass behavior is ignored and treated as bypass/equals for traffic to the spoke VNet. That means:
   • Same-VNet traffic is not hairpinned to the static route’s next hop, but
   • It is inspected by the security appliance in the hub and then routed directly to the destination IP in the spoke, when the conditions described in the routing-intent docs are met.
   Therefore, the statement “Routing Intent alone cannot force intra-VNet traffic through Azure Firewall when Bypass = Yes” is not supported by the provided documentation. With routing intent and the described static-route/propagation conditions, traffic to the spoke VNet is inspected in the hub and then sent directly to the spoke destination, independent of the bypass flag.

   2. When VNetLocalRouteOverrideCriteria = No (Bypass disabled)

   In the pure static-route scenario (no routing intent override):
   • Azure still uses longest prefix match.
   • Because the static route’s prefix contains the spoke VNet prefix, and vnetLocalRouteOverrideCriteria = "contains", traffic to IPs inside the spoke VNet is sent to the static route’s next hop (for example, an NVA or load balancer), enabling “hairpin” inspection.
   But when routing intent + Propagate static route are in play:
   • The documentation states that the bypass setting is ignored and treated as bypass/equals for traffic to the spoke VNet.
   • That means the behavior is effectively the same as the “bypass enabled” case for traffic to the spoke VNet: traffic is inspected by the security appliance in the hub and then routed directly to the destination IP in the spoke, bypassing the static route’s next hop IP.
   So the statement “Bypass = No effectively allows intra-VNet traffic to be hairpinned through the Secured Virtual Hub/Azure Firewall” is not correct in the routing-intent scenario described in the docs. With routing intent and Propagate static route enabled, the platform forces a behavior equivalent to bypass/equals for traffic to the spoke VNet, regardless of the configured bypass flag.
5. Summary aligned with the documentation
   • Without routing intent overrides:
     • Bypass = No (contains): static route next hop is used even for traffic to IPs inside the spoke VNet; this can create hairpin paths via an NVA/LB.
     • Bypass = Yes (equals): traffic to IPs inside the spoke VNet bypasses the static route next hop and goes directly to the VM; only traffic outside the spoke prefix (but within the static route range) uses the static route next hop.
   • With routing intent + Propagate static route enabled, or with a 0.0.0.0/0 static route:
     • The bypass setting on the VNet connection is ignored and treated as bypass/equals.
     • Traffic destined for IPs inside the spoke VNet is inspected by the security appliance in the hub and then routed directly to the destination IP in the spoke, bypassing the static route’s next hop IP.
     • This behavior follows the “traffic behavior with Bypass Next Hop IP enabled” example referenced in the docs.

References:

• Connect a virtual network to a Virtual WAN hub - portal
• Basic: Use routing intent with static routes
• How to configure Virtual WAN Hub routing intent and routing policies
• Securing internet access with routing intent
• Static routes in Virtual WAN
• Hub-spoke network topology that uses Azure Virtual WAN