Дизайн библиотеки и DI со сторонними зависимостями

Пишу библиотеку для внутреннего пользования. Цель этой библиотеки - абстрагироваться от вызовов некоторых внутренних REST API. Под капотом я использую Flurl для выполнения запросов. Библиотека также предоставляет методы расширений, которые настраивают DI (Core Web), чтобы легко связать все вместе (services.AddXYIntegration()). В случае flurl моя библиотека предоставляет реализацию DefaultHttpClientFactory (наследуется от IHttpClientFactory) => X509ClientFactory. Чтобы избежать коллизии или перезаписи DI приложений, использующих мою библиотеку, которые, вероятно, также используют Flurl для запросов https и хотят предоставить настраиваемую реализацию для IHttpClientFactory, я создал пустой интерфейс, просто чтобы «пометить» реализацию моих библиотек и использовать его в Проводка DI.

Немного битового кода:

public interface IX509HttpClientFactory : IHttpClientFactory 
{
    // empty interface, violates CA1040
}

public class X509HttpClientFactory : DefaultHttpClientFactory /* inherits from IHttpClientFactory */, IX509HttpClientFactory
{
    // Implementation details...
}

Таким образом, вместо того, чтобы вводить X509HttpClientFactory для IHttpClientFactory , библиотека создает экземпляр для IX509HttpClientFactory. IHttpClientFactory все еще "доступен" для инъекций.

Мой вопрос не относится к flurl, это более общий вопрос для подобных сценариев.

Это хороший дизайн? Как вы справляетесь с такими случаями, когда у вас есть настраиваемые зависимости сторонних производителей? Возможен ли сценарий нарушения CA1040.