As far as I understand from #3354, TypeRegistry is an internal implementation detail of the Type class whose API could and still can be used to register types and it hasn't been deprecated in favor of TypeRegistry. Why do consumers need to use the alternative internal API?

If the plan to replace Type with TypeRegistry, would it make sense to do as planned?

Why do consumers need to use the alternative internal API?

To be able to register instance of the classes. Type class is doing new $className() everywhere - that's unusable with DI. So that's why we need to use alternative API, because current API is bad. People are forced to use TypeRegistry, that's the only way how to register instance. But it's marked internal for some reason, even though it's stable for quite a while.

If the plan to replace Type with TypeRegistry, would it make sense to do as planned?

I think it would, but what work and what timeframe are we talking? I thought there was some blocker or unknowns if nothing was being done about this plan further, even though pieces were put in place. If this is only about replacing Type:: calls with Type::getTypeRegistry()->, I assume that should be pretty easy, but I'm not sure that's the plan here. Anything else might be complicated if BC is preserved and I don't want to wait much longer for this.

But it's marked internal for some reason, even though it's stable for quite a while.

Internal is not an antonym of stable.

If this is only about replacing Type:: calls with Type::getTypeRegistry()->, I assume that should be pretty easy, but I'm not sure that's the plan here.

I don't think anybody but @Majkl578 knows. I'd expect the type registry to be a dependency of the connection. Otherwise, it's not much better than the current static class.