Ktor Client and kotlinx.serialization JSON: Typed Response Deserialization Across Client Engines

When Ktor's client ContentNegotiation plugin is paired with kotlinx.serialization JSON, typed response bodies are deserialized using the installed Json instance and reified type parameters. The integration boundary appears straightforward for a single engine, but the research notes that engine behavior and coroutine suspension are not uniform.

Across CIO, OkHttp, Jetty, and Apache, the handling of missing or unregistered Content-Type headers may differ, and non-reified generic types cannot be reliably inferred at runtime. Additionally, coroutine suspension semantics vary: CIO is coroutine-native, while OkHttp and Jetty may block or dispatch on their own threads. Ktor major versions also change the ContentNegotiation API and package names, so compatibility assumptions must be pinned to a specific release line.

Which engine-specific behaviors must be accounted for when a shared HttpClient configuration is expected to deserialize typed JSON responses identically across engines, and how should callers handle parameterized types without relying on reified generics? Is there a documented contract for Content-Type fallback and suspension when the server omits the media type, or is this inherently engine-dependent and requiring explicit configuration?