We are seeing more and more examples where an estimator of one scitype should be considered as another, in composition.

Examples:

• using a clusterer as a transformation, in the TransformSelectForecaster - [ENH] Added clusterer support to TransformSelectForecaster #6848
• using a clusterer as a transformation, in pipelines
• using sklearn transformations as time series transformations, via TabularToSeries adapter.
• using a forecaster as a transformation, via in-sample forecasts.
• using a time series aligner that can produce distances as a time series distance, via DistFromAligner
• using a time series annotator - outlier, changepoint detector - as a transformation. This is even parametric, depending which output we map onto score. [ENH] ensure pipelines between changepoint/anomaly annotators, transformers, and other estimators integrate seamlessly #6591

I think the cleanest way to address these would be:

• write coercion wrappers for the individual transformation
• write a coercion layer, that collects standard ways to coerce objects of scitype X to objects of scitype Y.
  • the coercion layer could be attached to a to_scitype method that all base classes possess.
  • This would allow any user to pass more scitypes without explicit coercion, and developers to write more flexible composites by prefacing with a `to_scitype coercion.