Заметки о буфере, действительном до следующего вызова

Какой уже созданный объект владеет дескриптором библиотеки, пока идёт копирование? Если сама обёртка, этот ответ ломается, как только копирование бросит исключение. Поместите дескриптор в член handle_owner и дайте его созданию завершиться до начала копирования. Копирование бросает исключение. Полностью созданные члены, включая handle_owner, уничтожаются в порядке, обратном завершению их создания. Деструктор обёртки не вызывается. Дескриптор освобождён. Оставался ли исходный буфер действительным во время копирования, к этому отношения не имеет.

Удержать дескриптор живым как раз несложно, в Swift это может случиться и само собой. Класс владеет дескриптором и сохранённым callback, который сильно захватывает self. Цикл держит всё в живых, а следующий вызов библиотеки всё равно делает байты недействительными. Слабая ссылка убирает цикл. Тогда нужно решить, что делает callback, сохранённый где-то ещё, когда владельца уже нет. Ни один из вариантов не заменяет ваше правило о действительности буфера.

Второй вариант разваливается у меня там, где заимствованное представление держится через .await, и я до сих пор не уверен, что в асинхронном Rust есть чистое решение. Приостановленная future сохраняет заимствование всё время, пока стоит. Проверка заимствований запрещает только вызовы через тот дескриптор, у которого вы заняли. Другая задача на том же исполнителе может, пока ваша стоит, вызвать библиотеку через другой дескриптор, и если инвалидация идёт через общее состояние библиотеки, типы ничего не заметят. Если future Send, она может ещё и продолжиться в другом потоке, и ваш пункт про параллельность возвращается. А если представление указывает в буфер, которым владеет сама future, получается самоссылка, и вы уже на территории Pin. Так что, честно, я бы копировал до первого await. Сначала копия, потом ожидание. Скучно, зато это я могу объяснить.