You can post the missing "copy to clipboard" feature as a new issue in Electrum's GitHub page: https://github.com/spesmilo/electrum/issues
I've checked and v4.3.4 indeed can copy the previous transaction's outputs just by tapping one of them.

For the seed phrase, it's a security feature since it's stated that you should "write the seed phrase on paper", not keep in your device (e.g. via screenshot/clipboard)
I doubt that it'll be reintroduced to the new version.

I'm afraid only by uninstalling v4.4.1 and reinstalling the lower version, then restore your wallet's seed phrase.
Even if you managed to overwrite 4.4.1 with a lower version, the wallet file itself will still be incompatible with the lower version of Electrum.

Probably caused by installing the update while an instance of the old version was still running.
If not actively running, a "zombie" electrum process was still running in the backgound.

Because that'll prevent some files to be overwritten by the update.

That's just wishful thinking.
The most sane reason he/they did is because the "community" already discussed that puzzle 66+ is already hard enough to be worthy of that prize.

Also, the creator (for some reason) tends to include puzzle #1 whenever he decided to increase the prize.
Like when he spent 161~256 and sent it to the previously unclaimed ranges, he included #1 to the recipient: 5d45587cfd1d5b0fb826805541da7d94c61fe432259e68ee26f4a04544384164

If downgrading and restoring from the seed phrase is your current option,
temporarily rename your wallet file so Electrum wont be able to load it automatically, that'll prevent that error.
Alternatively, you can remove the "gui_last_wallet" line in the config file.

Your wallet/config file can be found in your Electrum data directory, "wallets" fodler: electrum.readthedocs.io/en/latest/faq.html#where-is-my-wallet-file-located

It's much simpler than before since it's pre-enabled in native SegWit wallets which is the default.

Simply tap the wallet name at the upper-left hand side of the screen and select "Channels".
In the Channels screen, tap "Open Channel" below the screen to establish a channel.

I'd suggest you to read the introduction and other notes in the link above because it's still relevant.

For bare addresses, there's no data or tag that'll link them to the HD source.
Those addresses are derived from their respective public key having steps using "one-way" hashing algorithms, namely, SHA256 and RIPEMD160.
The other steps are just for checksum, address type and encoding; there's nothing to link it back even just to the public key, more so, to the extended public key.

Then, for scenarios with spent inputs where the public key is exposed, there's no way to link them to the HD source either.
Those child (public) keys are derived from the extended public/private key using another one-way method "HMAC-SHA512" with different 'index'.
It simply impossible to compute the extended private key from the public key.

Read this for more info about how HD Wallets work and how the child keys are generated: learnmeabitcoin.com/technical/hd-wallets

But that doesn't mean that your privacy is certain.
As mentioned by others, there are methods that can potentially link them together; IMO, number one is using their associated UTXOs together in a single transaction.
Second is by connecting to a public server that's "investigating" Electrum users. (not all of them does but consider your privacy compromised by using public servers)

This may be caused by the common (non) issue of confusing the unit "mBTC" with "BTC".
Check if you're using the default mBTC while wanting to send at BTC unit.
Example, if you want to send "0.001 BTC" but typed '0.001' while using the 'mBTC' unit, the actual amount would be "0.000001 BTC" which is lower than the lowest possible fee.

If that's the case, you can change the unit in the settings: "Tools->Preferences->Units->Base unit".
If not the case, what's the actual "fee is 100%" message that you're seeing?

If you actually sent those transactions with very high transaction fee, there's nothing you can do to recover your bitcoins.

You'll have to enable logging and check the .log file to see what could've caused it.
Logging can be enabled in "Tools->Preferences->Misc->Write logs to file".
logs can be accessed in "logs" folder inside Electrum's data directory (location)

But AFAIK, no other users have reported such error.

Based on my small number of reported issues (about 2 or 3..),
developers usually reply within a day and proceed to commit a "fix" depending on the severity of the issue and if it falls under their priority list.

To be clear, you're talking about an issue you've posted in Electrum's GitHub Repository, right?

Some of cases like this are CPFP (Child-Pays-For-Parent) transaction.
Being mined at the same block and the child transaction having higher fee rate the parent indicated that it's that kind of transaction.

For those who are not familiar with CPFP, it's kind of a transaction bumping technique which spends the output of an unconfirmed transaction with higher fee to "bundle" their total fee and size together.
Essentially increasing the overall fee rate of the parent and child transactions.

However, none of the transactions in the OP are CPFP.
If not (un)intentionally set, those are probably "premium withdrawals" from a centralized exchange, wallet or casino.

Although the main context of this is true, linking the maximum bitcoin amount to the blockchain's size limit isn't.

Blocks will still continue to be mined even if we reached the maximum bitcoins, thus the blockchain will continue to grow despite miners getting zero block reward.
Otherwise, transactions will stop getting confirmations.

If it's just the "Master Private Key", a simple command getmasterprivate() can be used to extract it.
The user might also have to use convert_xkey() for it to be compatible with other wallets.

BTW, a forum user "HCP" has done that code modification 4 years ago: https://github.com/HardCorePawn/electrumBIP39 | Profile HCP

Nothing since it'll be a different wallet since adding a "BIP39 passphrase" would change the entire hierarchy of keys.
It wont derive the correct private keys from your old Bitcoin wallet.

That's assuming that you meant "BIP39 Passphrase" and not just the "Passphrase" for wallet encryption.

Hope this is digestible enough:
Your "HD" (Hierarchical Deterministic) wallet's private keys are all derived from a single "seed"
which is derived from your "seed phrase" plus the 'salt' "mnemonic" (if you didn't set one).

(don't be confused with "seed" and "seed phrase", the latter is your 12/24 words while the former is the initial entropy where your master key is derive from)

So, setting a 'BIP39 Passphrase' will extend the default passphrase 'mnemonic' which will change the resulting 'seed'.
And with that, a different 'seed' would derive a different set of private keys->public keys->addresses, thus an entirely different wallet.

---

This may be far-fetched but: The phrase in the title "this mysterious passphrase" also had me thinking that you may be talking about a bare passphrase without a seed phrase.
Because that may be the old "Brainwallet" which is a private key straight from the SHA256 hash of that passphrase.
Here's one example generator (only use it for testing purposes): https://brainwalletx.github.io/#generator

Probably not related to the update.
It means that it can't find any UTXO to add in order to fulfill the additional fee.
Most likely caused by using "max" amount and having no change output.

Your selected "method" is "Preserve Payment" which is set to keep the recipient's amount intact;
So, it'll have to provide additional input if your transaction doesn't have a change.

Selecting the other option should work in your case but it'll decrease the to-be-sent amount of bitcoins.

Try to install the full requirements listen on BTCRecover's "requirements-full.txt" file.
You can install those in one command:(if the requirements file isn't in python's directory, provide the absolute path)

By the way, is this related to your other topic where you're trying to bruteforce a wallet with unknown password using random characters tokens?
Because even with GPU acceleration, it'll be impossible for longer passwords.

Which instruction have you followed?

Because if it's my guide above, the online watching-only wallet will naturally show it as "watch only" since it's that type of wallet.
Your private keys should be in your offline machine that can be used to sign the transactions created by the watching-only wallet.

If you followed it correctly, you can do the final step "[To Create Transactions]" whenever you need to spend your bitcoins.

Chances is, your father meant he has "50000 BTCP".
Anyways, looking for his backup is still worth it.

And speaking of backup, any of those Electrum variants (One for Bitcoin, two for Altcoins) requires a "seed phrase"
to be written as backup before the user can finish creating his wallet.

So look for papers with words written on it (12 words by default) which should be the seed phrase that can restore his wallets(s).
If you found it, get an offline PC, install Electrum and go restore it via "Standard->I already have a seed" option.
Check the addresses (View->Show Addresses) if any has balance.

This should bring a closure to your doubt.

	Screenshot from version 4.3.4:	Screenshot from version 4.4.0:

Both do not display the inputs.
At first, I was wondering if you're talking about the transaction preview when sending bitcoins
but when I checked, it's the same as the screenshots above.

I'm assuming that you took OP's "MPK" as 'Master Private Key'.
Because otherwise, IanColeman's BIP39 tool cannot use his 'Master Public Key' and derive addresses from it.

Seems like the issue was the new hardened derivation path scheme which uses "h" instead of " ' ".

Your solution is kind of insecure since you've used non-hardened derivation paths for the "purpose", "coin" and "account" level which should be hardened by the standards.
If you're planning to use the wallet where you'll create a signed message, use this derivation path instead: m/44'/0'/0'