I'm marking this requires: discussion because to my understanding this could be bad for the same reason we don't provide dynamic linux triplets, even under community; because we have no means of arranging for the loader to ever find the right libs. (getting into community means we have to not know it won't work)

I do observe there already is an x64-osx-dynamic. Either:

1. osx is different than linux enough in how it finds dynamic libs that both triplets are fine, or
2. osx is exactly like linux and both this port should be rejected and x64-osx-dynamic should be deleted.

Related: #15006 #16332

Can't say I have deep knowledge in dynamic loading nor am I heavily invested either way for vcpkg; I only submitted this PR while testing vcpkg for a project and noticing there was no dynamic arm64 triplet.

For my purposes, the games I build on macOS use dylibs for things like SDL2 which use @rpath for their ID. When I build my app against those libs, I use Xcode's feature to embed and sign the dylibs so that my app bundle includes the dynamic libraries in the correct location in the bundle, with my executable configuring the rpath such that the dylibs load correctly.

I personally don't ever build and distribute non-bundled apps on macOS so that distribution channel might have more issues here, but I believe rpath can still be used there.

I see, so the bundling process fixes up rpath to be all relative within the bundle correctly? That is something meaningfully different than linux which argues to merge this.

After a conversation with @strega-nil we're going to merge this.

Thanks for your contribution!