Expanded on API stability to include feature flag details

Author: theoriginalbit

Sources/swift-openapi-generator/Documentation.docc/Proposals/SOAR-0012.md

@@ -298,9 +298,17 @@ The initializer expression will never need to provide the allowed values paramet
 
 This proposal creates new generated types and modifies the existing generated static functions for creating/accessing server definitions.
 
-The change could be backwards compatible to any adopter that relies on default values provided by the static server functions.
+#### New Feature Flag
 
-Adopters that do not rely on the default values will have compile errors, though migration should be a straight-forward change as adopters were previously unable to provide _any_ value due to runtime validation; the generated enum cases should have a similar spelling to the previous string counterpart.
+A feature flag, `serverVariablesAsEnums`, has been introduced to allow opt-in to the changes of this proposal. 
+
+When the feature flag is disabled the `RawStringTranslatedServerVariable` generator will be used for **all** variables, resulting in an identical output to the previous generator. However, when the feature flag is enabled the `GeneratedEnumTranslatedServerVariable` generator will be used for any variable that declares an enum field, and the `RawStringTranslatedServerVariable` generator will be used otherwise.
+
+#### Compatibility
+
+Given the previous generation, any adopter that relied on default values provided by the static server functions, e.g. `let url = try Servers.server1()`, will not experience any breaking changes by adopting the implementation from this proposal. The new generators will still provide valid default parameters, even for the generated Swift enums. Adopters that do not rely on the default values, however, will experience compile errors by adopting the changes in this proposal; though migration should be a straight-forward change as adopters were previously unable to provide _any_ value due to runtime validation, so the generated enum cases should have a similar spelling/shape to the previous string counterpart.
+
+#### Other components
 
 No API changes are required to other components, though once this proposal is adopted the runtime component _could_ remove the runtime validation of allowed values since the generated code guarantees the `rawValue` is in the document.