[ncmncm]

Makes me wonder why anybody takes them by value, and not by rvalue-reference.

But unique_ptr in public interfaces feels like code smell. I have done it, but not proudly.

[Const-me]

Quite a few times, I've made C++ library APIs like this:

    struct iface
    {
        virtual ~iface(){ }
        virtual void doSomething() = 0;
        static std::unique_ptr<iface> create();
    }

I don't know good ways to replace unique_ptr here.

Requiring library users to #include the concrete implementation is not good: inflates compilation time, pollutes namespaces, pollutes IDE's autocompletion DB.

Can go C-style i.e. pass double pointer argument to the factory, or return raw pointer. But then user needs to remember to destroy the object.

[ncmncm]

Returning them by value is fine. *RVO avoids inefficiencies.

But it would often be better to make a move-only value type, and return that instead.

[ncmncm]

Seriously: if you have to pass its address regardless, why pay to construct and destroy another one that you only wanted to std::move out of anyway?