Corect me if I’m wrong … but NOW I see a few major differences in these two “key management” schemes :

FROST vs BIP32 …

1: “sub key” derivation via FROST (called “shares”) can be initialized (once or multiple times) from a users EXISTING npub, providing forward compatibility for existing pubkeys to act as “main identities”. BIP32 (afaikt) must generate a fresh xpub as the “main identity”, excluding existing npubs from reaping the benefits?

2: FROST handles a variety of “multisig” scenarios OOTB, allowing increased security if end users desire it. Implementing BIP32 alone would not provide multisig functionality?

3: FROST libraries are currently in development and ready to be implemented in Nostr clients. BIP32 is not?

OTHERWISE …

- both solve for “disposable” pubkeys which are cryptographically linked to a “main identity” pubkey.

- both require additional implementation by signers and native clients.

- both require a “connected” signer or native client to request the “main identity” pubkey from some remote service.

Forgive my ignorance as I wrap my head around this very real need. Have I missed anything?