The framework currently expected settings to be passed in as a Dictionary<string, object>. The framework internally knows and expects certain types for each setting name. The API itself doesn't expose this and requires callers to know setting names and their expected formats or underlying types for settings to be received and processed. A clearer, strongly-typed API could improve the discoverability of which settings are supported by the framework and clearer communicate their types and intent.

This could be done in a non-breaking fashion through an overload (or other net-new mechanism) to be opted-into slowly over time, or as part of a breaking change requiring consumers an explicit migration step at the time they upgrade to a new major version.