[Multi-provider] Gaps identified relative to js-sdk reference implementation

Context

We conducted a cross-SDK comparison of all MultiProvider implementations using the js-sdk as the reference. The Python MultiProvider was implemented in #511 and is functional for basic use cases, but we identified several gaps relative to the reference implementation. Some of these were noted as future work in the original PR.

Note: Tracking forwarding is blocked by SDK-level tracking support (#374).

Gaps

1. Event aggregation and status tracking (High)

The MultiProvider passes child provider events through directly via attach/detach with no aggregation. If one child emits PROVIDER_ERROR while another is READY, both events propagate independently. There is no composite status, so consumers cannot determine the overall health of the MultiProvider.

Expected behavior:

• Maintain a per-provider status map
• Compute an aggregate status using "worst-wins" precedence: FATAL > NOT_READY > ERROR > STALE > READY
• Only emit an event when the aggregate status actually changes (deduplication)
• Always forward PROVIDER_CONFIGURATION_CHANGED events as a pass-through

Reference: js-sdk status-tracker.ts, dotnet-sdk HandleProviderEventAsync / DetermineAggregateStatus

2. Per-provider hook isolation during evaluation (High)

Hooks are aggregated into a flat list via get_provider_hooks(), meaning ALL child provider hooks run for ALL evaluations regardless of which provider actually evaluated the flag. The js-sdk reference runs each provider's hooks only during that provider's evaluation, with an isolated context copy to prevent cross-provider mutation.

Expected behavior:

• Run each child provider's hooks only when that specific provider is being evaluated
• Isolate hook context per-provider to prevent cross-provider mutation
• Execute the full before/after/error/finally lifecycle per-provider

Reference: js-sdk hook-executor.ts, go-sdk isolation.go, dotnet-sdk ProviderExtensions.EvaluateAsync

3. FirstMatchStrategy semantics (Medium)

The current FirstMatchStrategy.should_use_result() accepts any result where reason != Reason.ERROR. It does not distinguish FLAG_NOT_FOUND from other error types. The js-sdk reference treats FLAG_NOT_FOUND as "skip to next provider" but halts on any other error.

Expected behavior:

• FLAG_NOT_FOUND should cause fallthrough to the next provider
• Any other error (e.g. PARSE_ERROR, GENERAL) should halt evaluation and surface that error
• A successful result should be returned immediately

Reference: js-sdk strategies/first-match-strategy.ts

4. Add FirstSuccessfulStrategy (Medium)

Only FirstMatchStrategy exists. There is no FirstSuccessfulStrategy, which is more resilient by skipping all errors (including non-FLAG_NOT_FOUND errors) and continuing to the next provider.

Expected behavior:

• Return the first completely successful result (no error at all)
• Skip any provider that returns an error or throws, regardless of error type
• If all providers fail, collect and report all errors

Reference: js-sdk strategies/first-successful-strategy.ts

5. Add ComparisonStrategy (Medium)

There is no ComparisonStrategy for evaluating all providers and comparing results (useful for migration validation and consistency checks).

Expected behavior:

• Evaluate all providers (ideally in parallel)
• If all providers agree on the value, return it
• If providers disagree, call an optional onMismatch callback and return the designated fallback provider's result
• If any provider errors, collect and report all errors
• Constructor accepts a fallbackProvider and optional onMismatch callback

Reference: js-sdk comparison-strategy.ts, go-sdk comparison_strategy.go, dotnet-sdk ComparisonStrategy.cs

6. True parallel evaluation (Low)

The run_mode="parallel" option currently executes providers sequentially in a for-loop despite the name. The only difference from "sequential" is the lack of early exit. The docstring acknowledges this as a planned future enhancement.

Expected behavior:

• When run_mode="parallel", evaluate all providers concurrently (e.g. via asyncio.gather or ThreadPoolExecutor)
• Collect all results, then let the strategy determine the final result

Reference: js-sdk parallel evaluation in flagResolutionProxy

Blocked / Deferred

• Tracking forwarding: Requires SDK-level tracking support first (#374)

Related Issues

• #511 — Original multi-provider implementation
• #374 — Implement tracking in Python

Spec Reference

https://openfeature.dev/specification/appendix-a/#multi-provider

Start from the Python MultiProvider implementation from #511 and inspect its event handling, get_provider_hooks(), FirstMatchStrategy, and run_mode evaluation paths. Compare each gap with the linked js-sdk, go-sdk, and dotnet-sdk references. Done means implementing and testing the specified status, hook, strategy, comparison, and parallel-evaluation behavior, while leaving tracking deferred behind #374.