Context

This proposal is adjacent to, but different in scope from, two issues:

• Explain why discouraged features are discouraged #3210 focuses on adding explanations for discouraged features.
• "Limited availability" when not actually available? #1988 discusses confusion around the “Limited availability” label and UI language.

By contrast, this is a data/schema‑level change: add a sub‑property under status that explains why a feature isn’t Baseline. It’s backward‑compatible and gives downstream tools a consistent reason they can use to explain “limited availability,” without dictating any UI wording.

Problem

Today, status.baseline === false covers situations that require different guidance. From the current schema, we can detect:

1. Discouraged legacy features: via the top‑level discouraged object.
2. Not shipped anywhere (prototype/early): when status.support is an empty object.
3. Shipped somewhere but not Baseline: when status.support has one or more browser keys, yet baseline:false remains.

A simple, unified reason field would let downstream tools and docs explain the “not Baseline/limited availability” case more clearly and actionably.

Proposal

• Add a sub‑property that says why a feature is not Baseline, e.g. under status:

"Status": {
 "type": "object",
 "properties": {
   "baseline": {
     "description": "Whether the feature is Baseline (low substatus), Baseline (high substatus), or not (false)",
     "enum": ["high", "low", false]
   },
+   "reason": {
+     "description": "Short reason when baseline is false (optional)",
+     "enum": ["discouraged", "insufficient_coverage" ...  ]

I suggest exposing reason as a enum so values stay stable across tools.