Product Decisions This Supports

Adopt vs. upgrade decision: v2.0.0 is a cleanup major release, not a feature release. New adopters should start on v2; existing apps should upgrade only after confirming they do not rely on the deprecated Channor\HashedRouteKey API, legacy hashed-route-key config, HASHED_ROUTE_KEY_SALT fallback, legacy publish tag, or Composer replacement metadata.
Migration planning: Treat this as a controlled breaking change. Budget for dependency/code audit, config cleanup, and regression testing around route-key generation and route model binding.
URL and client stability: The release preserves codec defaults and attempt-0 behavior, which supports keeping existing generated route keys stable. Validate this in staging before rollout because URL churn would affect bookmarks, links, API clients, and SEO.
Support lifecycle: v2 reduces legacy surface area and maintenance burden. Apps that still need the deprecated v1 API should intentionally remain on channor/opaque-route-key:^1.1, with a documented plan to migrate later.
Build vs. buy: For teams that need opaque Laravel route keys without building custom codec/salt handling, v2 is a cleaner buy candidate. The added docs/upgrade-v2.md supports a buy-and-upgrade path rather than a fork.

When to Consider This Package

Consider it when a Laravel app needs opaque route keys for public-facing model URLs and wants to keep route generation stable across this major upgrade.
Adopt v2 for new work if the app does not need the deprecated Channor\HashedRouteKey compatibility layer and can use the streamlined config model.
Upgrade existing apps when the team can audit for legacy config/env usage, verify route-key stability, and accept a major-version migration.
Look elsewhere or defer if the app depends on Channor\HashedRouteKey, legacy hashed-route-key config, HASHED_ROUTE_KEY_SALT, the old publish tag, or Composer replacement behavior and cannot migrate promptly.
Look elsewhere if the requirement is full encryption, signed URLs, authorization, or native UUID/ULID route keys rather than opaque route-key generation.

To executives: v2.0.0 is a maintainability release that removes deprecated compatibility code and legacy configuration. It reduces long-term support surface while preserving route-key generation defaults, so existing URLs should remain stable if the app is not using deprecated APIs.
To engineering: This is a breaking major version, but the breaking changes are explicit: old v1 API, config, env fallback, publish tag, and Composer metadata are removed. Use the v2 upgrade guide, audit for legacy usage, and regression-test route binding and key stability.
To product/operations: Approve the upgrade when migration capacity exists and URL stability is verified. If the app still depends on the deprecated API, stay on ^1.1 temporarily and schedule migration rather than forcing an unsafe upgrade.