Knockout component binding and custom element param boundaries: typed expression vs string attribute coercion

Knockout's component binding and custom elements share the same ko.components registry and loader, but they diverge at the interoperability boundary. The component binding treats params as an arbitrary JavaScript expression, so objects, observables, and functions pass through intact. Custom elements coerce every attribute except params to a string, meaning non-string values must be routed through the params expression or referenced indirectly.

Update semantics introduce another unresolved decision. Knockout does not re-create a component instance when its params change; the viewModel constructor runs once per element instance. Authors must therefore decide whether to subscribe to passed observables inside the viewModel or force teardown by keying the component name or wrapping it in an if/foreach binding. Because custom elements arrived around the 3.2 line and ko.options.deferUpdates in 3.4, the visibility of a param-driven update relative to DOM events can vary by minor version.

For a component intended to work identically under both entry points, should the viewModel assume stable observable identities and mutate contents, or should the binding layer normalize attributes before construction? How should version-specific notification timing be accounted for when the same component is consumed via a custom element and via the component binding?