add feature flags, reword codemods

Author: sentrivana

develop-docs/sdk/processes/breaking_changes.mdx

@@ -96,8 +96,9 @@ Fortunately, there is always a lot you can do (and not do) to make the upgrade p
 
 - Call-outs in relevant places in the docs and in the changelog.
 - Deprecation warnings that a breaking change is coming.
-- Supporting an intermediate period where both the old and the new way of doing things works.
-- A polished migration guide with a lot of easily copy-pastable before-and-after examples.
-- Trying to do the upgrade yourself on a test app. Instruct an LLM to do the update using your migration guide and see how well it works.
-- Providing a tool that helps with the upgrade, for example using codemods.
+- Support an intermediate period where both the old and the new way of doing things works.
 - Maintain deprecated APIs, if possible, for another major version.
+- Add an SDK option that acts as a feature flag to enable users to switch between the old and the new behavior.
+- A polished migration guide with a lot of easily copy-pastable before-and-after examples.
+- Try to do the upgrade yourself on a test app. Instruct an LLM to do the update using your migration guide and see how well it works.
+- Provide a tool that helps with the upgrade, for example using codemods. (Caveat: This is tricky to get right so that it covers all possible usages of the SDK.)