¿Por qué std::shared ptr:: unique() está obsoleto?

¿Cuál es el problema técnico con std::shared_ptr::unique() que es la razón de su desaprobación en C++17?

Según cppreference.com, std::shared_ptr::unique() está en desuso en C++17 como

Esta función está obsoleta a partir de C++17 porque use_count es solo una aproximación en un entorno multihilo.

entiendo que esto es cierto para use_count() > 1: Mientras estoy sosteniendo una referencia a él, alguien puede, simultáneamente, dejar ir de su o crear una nueva copia.

Pero si use_count() devuelve 1 (que es lo que me interesa cuando llamo a unique()), entonces no hay otro hilo que pueda cambiar ese valor de una manera picante, así que esperaría que esto sea seguro:{[18]]}

if (myPtr && myPtr.unique()) {
    //Modify *myPtr
}

Resultados de mi propia búsqueda:

Encontré este documento: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0521r0.html que propone la desaprobación en respuesta a C++17 CD comment CA 14, pero no pude encontrar dicho comentario en sí.

Como alternativa, ese documento propuso agregar algunas notas, entre ellas las siguientes: {[18]]}

Nota: Cuando múltiples subprocesos pueden afectar el valor de retorno de use_count(), el resultado debe ser tratado como aproximado. In particular, use_count() == 1 does not imply that accesses through a previously destroyed shared_ptr have in any sense completed. - nota final

Entiendo que este podría ser el caso para la forma use_count() se especifica actualmente (debido a la falta de sincronización garantizada), pero ¿por qué la resolución no se limitó a especificar dicha sincronización y, por lo tanto, hacer que el patrón anterior sea seguro? Si hubiera una limitación fundamental que no permitiera tal sincronización (o la hiciera prohibitivamente costosa), entonces ¿cómo es posible implementar correctamente el destructor?

Actualización:

Pasé por alto el caso obvio presentado por @ alexeykuzmin0 y @ rubenvb, porque hasta ahora solo usé unique() en instancias de shared_ptr que eran no es accesible a otros hilos. Así que no había peligro de que esa instancia en particular fuera copiada de una manera picante.

Todavía estaría interesado en saber de qué se trataba exactamente CA 14, porque creo que todos mis casos de uso para unique() funcionarían siempre y cuando se garantice la sincronización con lo que suceda con diferentes instancias shared_ptr en otros subprocesos. Así que todavía me parece una herramienta útil, pero podría pasar por alto algo fundamental aquí.

A ilustrar lo que tengo en mente, considere lo siguiente:

class MemoryCache {
public:
    MemoryCache(size_t size)
        : _cache(size)
    {
        for (auto& ptr : _cache) {
            ptr = std::make_shared<std::array<uint8_t, 256>>();
        }
    }

    // the returned chunk of memory might be passed to a different thread(s),
    // but the function is never accessed from two threads at the same time
    std::shared_ptr<std::array<uint8_t,256>> getChunk()
    {
        auto it = std::find_if(_cache.begin(), _cache.end(), [](auto& ptr) { return ptr.unique(); });
        if (it != _cache.end()) {
            //memory is no longer used by previous user, so it can be given to someone else
            return *it;
        } else {
            return{};
        }
    }
private:
    std::vector<std::shared_ptr<std::array<uint8_t, 256>>> _cache;
};

¿Hay algo malo en ello (si unique() realmente se sincronizaría con los destructores de otras copias)?