Shopware concedes @deprecated was the wrong signal, and splits it in 6.7.14.0

The concession in Shopware's post is about incentives rather than syntax. A tag that fires on every call site of a method that will keep working teaches extension developers exactly one habit, and Shopware says it considered blessing that habit by recommending more ignore patterns, then rejected it, because a blanket ignore also swallows the deprecations where migration genuinely is required ^[9]. Its own reading is that PHPStan was not too strict; it was being handed the wrong signal ^[9].

One boolean flag cannot say which kind of dependency a plugin has. Narrowing a parameter type breaks callers that pass values outside the future type, while widening that same parameter is harmless to callers and can make an overriding method incompatible ^[8]. Return types run the other way, because PHP return types are covariant: a narrower return type leaves callers alone but can force subclasses that redeclare the method to adjust ^[10]. Calling a method and overriding it are different forms of dependency, and the old annotation could express neither that distinction nor the future type, parameter name, default value, or affected audience in a form a tool could read ^[12].

The arithmetic of the replacement is worth stating plainly. The `reason:*` markers announced five categories of planned change ^[4]. The `BCChange` namespace ships 15 concrete attributes ^[6], roughly three times the granularity ^[14], with directional names such as `ReturnTypeNarrowing` and `ReturnTypeWidening` ^[13], so direction is part of the type instead of part of the prose.

Delivering this in 6.7.14.0 rather than in 6.8.0 is the part that has to be right for the rest to function: metadata describing a major release has to live in the branch you are leaving, not the one you are entering ^[15]. That also fixes where the remaining work sits. A plugin can only pre-migrate if its pipeline runs the older line with tooling that understands the attributes, and Shopware's claim is that the attributes carry enough structured information for PHPStan, Rector and IDEs to reason about them ^[5], which is a statement about what is now possible, not about what those tools do today. The near-term benefit Shopware claims for itself is narrower and more credible: less noise for extension developers ^[17].