This is a follow-up from #13671 that lists some tasks that were intentionally left out from #13980:

• Work on the Symbol API: Functions like as_type, unwrap_or, unwrap_or_never ignore possibly-unboundness. Look into call sites of those functions and see if that's really what we require in all cases. Possibly remove some of these functions.
• .unwrap_or is currently only used with Type::Never. We did this to keep existing behavior for some cases where we then proceed to call .call(…), where Type::Never would lead to a "not callable" error, just like Type::Unbound before. This can be handled more explicitly, potentially with better diagnostics for the user.
• Understand if we need to handle the possibly-unboundness of the replacement argument in Symbol::replace_unbound_with. Write tests.
• Investigate and understand the performance gains of [red-knot] remove Type::Unbound #13671.
• Possibly look into undeclared-ness issues brought up here. See also the corresponding TODO comment in types.rs. => moved to Inconsistency between unbound and undeclared symbols ty#229
• Clarify if we want a diagnostic for in the situation described here => moved to Inconsistency between unbound and undeclared symbols ty#229
• Review the Type::Union case in the Type::member() function, potentially write some more tests