Yes. duck takes ownership of the vector by moving it into its internal storage.
As a bonus, if you tried passing in an lvalue, it will reject the input unless you add the "copyable" trait, so it ends up mitigating some hidden copies.
I don't have any numbers, but it is pretty slow. You can try making some edits in Compiler Explorer to see for yourself (though that of course has some impact from network requests).
One reason is that, like you said, the feature is still new. Additionally I made pretty liberal use of the std::ranges library in my implementation which has notoriously bad compile times. That could be an area to improve upon.
Another may be a bit more structural. If you want to call myObj.foo() via reflection, you have to linearly search members_of(myObj) for the one named "foo", and then call that. Actual compilers I assume use some kind of hash table.
The hand-waving solution is "put it in a PCH", but I am hoping to put some more effort into optimizing build time here in the future.
This library tries its best to mitigate that, catching common errors and whatnot, but it can definitely still happen. C++ doesn't have full token injection yet, so it avoids some of the more common pitfalls, if incidentally.
As an aside, you may want to check out Jai's approach. I believe everything you generate statically gets turned into a file by the compiler for debugging purposes, which it provides references to in the output.