When creating a new account, geth produces the following example output (from v1.9.1):
Shell> geth --datadir node1/ account new
INFO [07-30|10:06:07.556] Bumping default cache on mainnet provided=1024 updated=4096
INFO [07-30|10:06:07.561] Maximum peer count ETH=50 LES=0 total=50
Your new account is locked with a password. Please give a password. Do not forget this password.
Passphrase:
Repeat passphrase:
Your new key was generated
Public address of the key: 0xD6Fe976DCC6FdB1a383B0ed2e2b1147DDEc20a9a
Path of the secret key file: node1\keystore\UTC--2019-07-30T14-06-28.729791800Z--d6fe976dcc6fdb1a383b0ed2e2b1147ddec20a9a
- You can share your public address with anyone. Others need it to interact with you.
- You must NEVER share the secret key with anyone! The key controls access to your funds!
- You must BACKUP your key file! Without the key, it's impossible to access account funds!
- You must REMEMBER your password! Without the password, it's impossible to decrypt the key!
I count five references to a "password" but at the points where a user is actually interacting by entering something, it's a "passphrase." The same is true when trying to unlock an account on geth startup without using the --password command-line argument; the prompt is for a "passphrase" and often buried by being displayed over other output, not at the end of what's displayed.
Comments on this answer suggest that the language inconsistency is the source of at least some confusion that may impact user security.
Use one term consistently. I suggest "password" as that is the command-line flag and already built into several scripts, demos etc.
Mix use of the terms "password" and "passphrase" apparently referring to the same thing.
Thanks so much for pointing this out!
Ok, let's replace all passphrase instances to password. This will avoid breaking the CLI API (flag).
I searched "passphrase" in the whole geth project, and found 412 occurrences. Do they all need to be replaced with "password"? Do some of "passphrase" have any special implication?

Most helpful comment
Fixed by https://github.com/ethereum/go-ethereum/pull/19932