In the case of needing to create new self sigs (for example to add policy-urls or notations):

gpg --no-greet --expert --cert-policy-url http://example.com/policy --sign-key <keyid> <keyid>

If the --expert flag is not given gpg will just say that there is nothing to be done.

gpg --no-greet --list-sigs <keyid>

Will show both signatures. The old sigs will still float around the network as they have not been revoked. Compliant implementations will only use the most recent signature. The old signatures can be trimmed from the local key using:

gpg --no-greet --edit-key <keyid>
...
gpg> minimize
...
gpg> save

But if one redownloads the key from the keyservers the old sig is probably still there, as keyservers always merge when receiving an update.

Assuming a master+subkey setup, where the goal is to make the subkeys available on a network connected machine (laptop), additional security can be gained by changing the passphrase of the subkeys. This will give additional security to the master key - if the passphrase was keylogged on the laptop, and somehow the attacker managed to get to the offline-securily stored master key, they will still not be able to access it.

In the secure environment:

# create master+subkeys as usual.
$ mkdir /tmp/laptop
$ chmod 700 !$
$ gpg --export-secret-subkeys <keyid> >/tmp/subkeys.gpg
$ gpg --homedir /tmp/laptop --import </tmp/subkeys.gpg
$ gpg --no-greet --homedir /tmp/laptop --edit-key  <keyid>
Secret key is available.
...
gpg> password
Secret parts of primary key are not available.

You need a passphrase to unlock the secret key for
...
Enter passphrase:

Enter the new passphrase for this secret key.

Enter passphrase:
Repeat passphrase:
gpg> save
$ 

/tmp/laptop/ is now ready to be transfered across.

Note that these steps have to be repeated for every modification/addition of subkeys.