MobX 6 decorator support: choosing between transpiler legacy config and makeObservable migration

Goal: decide on a sustainable approach for using decorator syntax in MobX stores when moving from version 5 to 6, ensuring that the chosen path works with current tooling and does not re‑introduce action‑safety regressions.

Constraints: MobX 6 no longer ships built‑in decorator support, so existing @observable/@action code requires either a Babel/TypeScript legacy‑decorator setup or a rewrite to makeObservable/makeAutoObservable in constructors. The default enforceActions changed to 'observed', which will throw on untracked mutations unless the store is updated. Tooling support for legacy decorators is shifting, and the TC39 proposal semantics differ from the older legacy behavior, making long‑term stability uncertain.

Questions: Should teams keep legacy decorator transpilation to avoid rewriting code, or migrate to makeObservable/makeAutoObservable for future‑proofing? What are the impacts on build complexity, bundle size, and maintainability? How does the chosen decorator strategy interact with the enforceActions default and incremental migration steps?