Is InMemoryFlag.state intended to be honoured? DISABLED is never read

从 openfeature/provider/in_memory_provider.py 中的 InMemoryFlag.state 和 resolve() 开始，然后对比 issue 中描述的、文档所述的跨语言禁用 flag 行为。确认 Python 是否应遵循 DISABLED，还是仅为兼容性而保留该字段。完成的标准是：已决定并记录预期行为；如果 maintainers 选择进行更改，则已更新相关的内存中 provider 行为或测试。

InMemoryFlag declares a state field with an ENABLED/DISABLED enum, and as far as I can tell nothing ever reads it. Asking because "the field is there for API compatibility and honouring it was never promised" is a perfectly good answer, and I would rather have it recorded than assume a bug.

What I see

openfeature/provider/in_memory_provider.py:

class InMemoryFlag(typing.Generic[T_co]):
    class State(StrEnum):
        ENABLED = "ENABLED"
        DISABLED = "DISABLED"

    default_variant: str
    variants: dict[str, T_co]
    flag_metadata: FlagMetadata = field(default_factory=dict)
    state: State = State.ENABLED        # line 47
    ...

    def resolve(self, evaluation_context):
        if self.context_evaluator:
            return self.context_evaluator(self, evaluation_context or EvaluationContext())
        return FlagResolutionDetails(
            value=self.variants[self.default_variant],
            reason=Reason.STATIC,
            variant=self.default_variant,
            flag_metadata=self.flag_metadata,
        )

grep -n state in_memory_provider.py returns exactly one line — the declaration above. State.DISABLED does not appear anywhere else in the package.

So a flag constructed with state=State.DISABLED resolves to its own defaultVariant with reason STATIC, as though it were enabled.

Why I think it may be worth changing

For comparison, across the other in-memory reference providers:

Two of the four substitute the caller's default with reason: DISABLED and no error; Go agreed that was the right answer when it was raised. That is convention rather than specification — I could find no numbered requirement saying what a provider owes a disabled flag — so this is not a conformance claim, just a consistency observation.

Also worth noting the two shapes in the ecosystem: state: ENABLED|DISABLED in Go, Python and flagd's flag format, versus disabled: boolean in JavaScript, Java and Appendix B's test-flags.json. Not something to fix here, but it is why the field probably exists in this shape.

Questions

1. Is state intended to be honoured by resolve(), or is it carried for configuration compatibility only?
2. If it should be honoured — is the intended behaviour the caller's default with reason: DISABLED and no error code, matching JavaScript and Java?
3. Would you rather the field were removed than implemented, if honouring it is not wanted? A declared field that is never read seems the more surprising of the two states.

Context

Found while building the cross-language provider conformance suite proposed in open-feature/spec#417. A new gated @disabled-flags capability is left undeclared for the Python in-memory suites on the strength of this, and the four scenarios skip rather than fail — so nothing is blocked. Recording the question so the reason for that gate is not just in my head.