Краткий ответ

Generic-параметр сохраняет конкретный тип, поэтому метод, возвращающий Self, возвращает именно этот тип: из T получается T. Existential-значение скрывает конкретный тип; современный Swift может открыть его на время вызова и получить результат, связанный с динамическим типом значения, но вызывающий код не может считать результат заранее известным конкретным типом.

Поэтому результат existential-вызова можно вернуть как другой existential или передать в контекст, поддерживающий соответствующий протокол, но нельзя без дополнительной проверки присвоить его, например, переменной конкретного типа Document.

Исторический контекст

Протоколы решают две разные задачи: описывают общий интерфейс и позволяют работать с неизвестными реализациями. Generic-код обычно сохраняет информацию о конкретном типе на этапе компиляции, а existential намеренно стирает её за контейнером any P.

Требование с Self особенно явно показывает эту границу. Оно связывает результат метода с типом, на котором метод вызван, поэтому важно отличать сохранение типовой идентичности от простого доступа к общим требованиям протокола.

Постановка проблемы

Пусть протокол описывает клонирование и требует вернуть значение того же конкретного типа. Для generic-функции это естественно: если параметр имеет тип T, результат также имеет тип T.

У existential-значения внутри контейнера может находиться любая реализация протокола. Статический тип контейнера не сообщает вызывающему коду, является ли скрытый тип Document, Image или другой реализацией. Если бы Swift разрешал считать результат конкретным типом без проверки, это нарушило бы типобезопасность.

Подробное решение

При работе с generic-параметром компилятор связывает Self с конкретным аргументом типа. Например, для вызова с Document параметр T становится Document, а метод возвращает Document.

При работе с any Clonable Swift знает только, что внутри находится некоторое значение, соответствующее Clonable. Современный механизм เปิดтия existential на время вызова позволяет вызвать ковариантный метод, возвращающий Self, но результат получает специальную связь с открытым скрытым типом. Эта связь не превращает результат в произвольный заранее известный конкретный тип.

protocol Clonable {
    func clone() -> Self
}

struct Document: Clonable {
    let id: Int
    func clone() -> Document { self }
}

func cloneGeneric<T: Clonable>(_ value: T) -> T {
    value.clone()
}

func cloneAsExistential(_ value: any Clonable) -> any Clonable {
    value.clone()
}

cloneGeneric сохраняет точный тип T. cloneAsExistential также может вернуть результат, но только как any Clonable; вызывающий код не вправе предположить, что это именно Document.

Ограничение проявляется, когда результат требуется использовать как конкретный тип. Для этого нужны проверка типа, приведение, дополнительный внешний контракт или generic-интерфейс, который сохраняет типовую связь. Простое соответствие протоколу не доказывает равенство скрытого типа конкретному типу вызывающего кода.

Следует отличать возвращаемый Self от параметра типа Self. Возвращаемый Self во многих контекстах допускает открытие existential, поскольку результат можно безопасно упаковать обратно в existential. Передача произвольного значения в параметр Self требует, чтобы его тип совпадал с неизвестным скрытым типом, чего внешний код обычно доказать не может.

Ситуация из практики

В приложении есть реестр расширений, хранящий разные объекты, поддерживающие клонирование. Реестр использует [any Clonable], потому что конкретные типы расширений различаются. При клонировании он может вернуть any Clonable, после чего клиент работает только с общим интерфейсом.

Рассматривались два варианта. Использование generic-функции сохраняет точный тип и удобно для кода, который уже знает тип объекта, но не подходит для однородного хранилища разных реализаций. Приведение результата к конкретному типу сохраняет больше возможностей для одного клиента, но требует проверки и ломается при добавлении новых реализаций.

Выбранное решение — разделить границы: внутри типизированных операций использовать generic-параметры, а на границе реестра возвращать existential. Это сохраняет типобезопасность, не заставляет реестр знать все конкретные типы и явно показывает место, где типовая информация намеренно стирается.

Что кандидаты часто упускают

Можно ли вызвать метод, возвращающий Self, через any P?

В современном Swift такой вызов часто допустим благодаря открытию existential. Однако это не означает, что результат имеет известный статический конкретный тип: его можно использовать в совместимом абстрактном контексте или снова упаковать в existential, но нельзя автоматически считать экземпляром выбранного типа.
Чем результат generic-вызова отличается от результата existential-вызова?

Для T: P компилятор сохраняет идентичность T, поэтому результат типа T можно передать в другую generic-операцию, требующую тот же тип. Для any P скрытый тип может быть открыт только в рамках допустимого вызова; наружу обычно передаётся абстракция, а не конкретный тип.
Решает ли type erasure проблему сохранения точного типа?

Нет. Type erasure намеренно скрывает конкретный тип и обычно предоставляет возвращаемое значение как any P либо через собственный erased-интерфейс. Он решает задачу хранения и передачи разнотипных реализаций, но не восстанавливает статическую связь, которую сохранял бы generic-параметр.