window.nostr.getPublicKey() outputs your npub. Frostr doesn't change that.

Frostr works with your existing nsec and outputs your existing npub.

Frostr allows you to put your nsec into cold storage, and use it to generate new sets of shares offline. It doesn't change your nsec/npub.

Frostr simply splits your nsec into many shares, so that one device does not hold your entire npub, only a part of it.

BIP32 works with frostr (technically not yet, have to fix a bug first), so you can derive child keys from your nsec, and frostr can sign with those child keys.

BIP32 is not utilized by nostr AFAIK, so child npubs will not be recognized as an extension of your main npub. However if nostr protocol decides to implement BIP32 (or any key derivation scheme really), then frostr will work with it.

Using your nsec with frostr also does not lock you into using frostr. It doesn't do anything strange or proprietary to the final signature, so your bare nsec/pub will validate signatures made with frostr.

From a cryptography perspective, you cannot tell the difference between a signature from frostr, or from your bare nsec. They are the same signature.

I hope this helps.