> Moreover, it breaks the systematic approach of sending messages to an instance (often presented as one of the key arguments in favor of object-oriented programming).

Is this just a matter of “the code will become spaghetti once too many classes/methods/implementations exist”? And, conversely, is a non-static method with a constrained, i.e. somehow different type (or also the approach of moving a method outside of the class proper) not more confusing?

I'm building a new language and just a couple of days ago the concept of guard methods came up as I was trying to tighten up equality semantics to be more like Swift.

Things like Array.contains() only work if the element type implements the Equatable interface, so it would be a guard method. Maybe something like:

    class Array<T> {
      contains(value: T): boolean where T extends Equatable { ... }
    }

    class Array<T> {
      contains(this: Array<T extends Equatable>, value: T): boolean { ... }
    }

C++ has this feature. When you define a template class, you can use SFINAE (or, in modern C++, concepts) to make it so that certain methods only exist if the template parameter meets certain requirements.

(Though even this is often unnecessary - for something like your `flatten` example, you could just go ahead and define it unrestricted. Methods of template classes are typechecked lazily - in other words, they don't need to successfully typecheck unless they're called. For this specific use case, SFINAE/concepts would just make the error message nicer.)

Rust also has this feature, with conditional impls.