You cannot swap out the wallet or import any keys if you have pruning enabled. Pruning ensures that Bitcoin Core only keeps what is necessary and pertaining to the wallet that was loaded during synchronization. If you want to use both wallets interchangeably and swap them out without a reindex, you have to disable pruning.

Was your target wallet selected and loaded during the synchronization?

It doesn't. It should only show the Bitcoin Cash that is in those addresses.
Yes. Go to Console and type in this:
ismine("ADDRESS").

If the response is false, then you have the wrong wallet. If the Console is not in the tabs, go to View and Show Console.

---

Another possibility which is also quite likely is that the address that you've generated is not within the gap limit. For that, just key in this into the console:
[wallet.create_new_address(False) for i in range(100)].

The command above generates 100 additional addresses. This assumes that you have generated and used at least 100 additional addresses from the 2017 to the current day. You can increase the integer as necessary.

No. You can't send BCH to bech32 addresses because they're invalid. You can't recover funds sent to nested segwit addresses because they are anyone can spend.

Or P2SH.

Bitcoin Cash doesn't support Segwit, for obvious reasons and if you manage to send Bitcoin Cash to a Bech32 address, the transaction couldn't have gone through or a nested Segwit address, then it's gone for good. Multisig and other script standards are fine.

BIP39 defines the seed phrase standards and this means that the wallet could be having a BIP39 process to convert the phrases into a seed. The derivation path is a whole different story and loads of wallets don't share the same derivation path or the same standards. Having a weird derivation path is completely normal but having a close source wallet is not advisable.

The sole purpose of a hardware wallet is for the user to be able to spend the funds without exposing their private key to unnecessary risk. In a sense, it is designed to secure the private key by keeping it within the device and making it resistant against any malware attacks, or other extraction techniques. You shouldn't bring your hardware wallet everywhere in the first place, it's another unnecessary risk.
Which is why it tells you to keep the seeds safe.
Hardware wallets are not offline. The way they are designed makes it immutable to malware attacks as the microcontroller is designed to not get compromised through the USB. Airgapped wallet does the same thing with one key difference with hardware wallets. The seeds are stored within the secure element which cannot be extracted or brute forced in the event that it gets stolen. They are specifically designed to resist physical attacks and sidechannel attacks. It depends on your use case; if you're going to keep your cold storage in a safe and don't mind the hassle with using it, then it'll be better that way.

It is possible. But it is incredibly unlikely. The total number of addresses are 2^160 due to the nature of RIPEMD160 for P2PKH while the total number of (possible) private keys would be 2^256 (a little less than that). This makes it such that there would be 2^96 private keys that corresponds to an address.

To find a specific address, you'll need to generate about 2^160 keys before you can find it. The safeguard is the math behind this; it is simply not feasible for anyone to generate even half of the sufficient keys within any remotely feasible amount of time (thousands of years). That is provided that the keys are generated unpredictably.

The disagreements with bigger blocks arises from the different camps supporting either Segwit or larger blocks. Full nodes are essentially the cogs within the blockchain which enforces the rules for SPV clients as well as those which relies on them for information. The pools actually have direct connection to each other, as demonstrated by the 2015 SPV mining forks. It doesn't matter if there is thousands of very slow nodes; miners will always connect to each other for the best chances, see FIBRE and similar implementations.
Hard fork exists because nodes are the ones which has a say in what rules Bitcoin should enforce and thus resulting in older versions of it being incompatible solely because they are enforcing the older rules, miners should not be able to dictate the protocol rules. Without a full node, how do you ensure that miners won't start mining 1000BTC block rewards? Full nodes are the ones enforcing it, you are not validating the block if you are running SPV client. It seems far easier for the miners to just collude and cheat everyone else if people are not able to verify the blocks.

Not all of the entities actually agreed to Segwit in the end, that is why Bitcoin Cash was spawned.

The idea behind Bitcoin is being trustless. Only those who can verify the blocks (ie full nodes) are able to verify that the blocks are following the rules as stated. SPV clients do not verify anything; they just follow the longest chain. There is no economic principles in play if you were to centralized mining to that extent; no one else being able to verify the blocks essentially means that everyone has to trust the miners. I'm surprised how your argument went from Bitcoin being easily manipulated by governments through ridiculous policies to making it even easier to manipulate by putting all the power into a small group of miners.

Nodes are what keeps the network secure. Without validating nodes, miners can do anything that they want with no concept of game theory or economic principle.
Again, ASICs didn't exist. One CPU One Vote was Satoshi's idea. Pools didn't exist. Bitcoin was stated as a currency for micropayments. By definition, a full node is one that downloads and validates the entire block. SPV concept was mentioned in the whitepaper as well.

If you're looking to keep it for the long term, then taking it out and putting it in a non-custodial wallet like Electrum and Wasabi wallet would be much better. It gives you the full control over your own coins and there are no disadvantages to this.

For the short term, you'll probably find it better to keep it on the exchange. Fees tends to spike erratically and you might miss on the ATHs to sell as you won't be sure about when your transaction would get confirmed when transferring to Coinbase.

None of the inputs were spent in another transaction. It is just a simple case of Blockchain.info giving incorrect error messages.

If you were to push the raw transaction manually, you'll realize that it'll throw an error saying that the fee is too low. It's due to their mempool being full and thus raising the mempool fees. That's all.

No. Restricting yourself to only be able to send the funds to certain addresses effectively locks your funds if the specified addresses are compromised or lost. Scripting standards also don't allow any functions that restricts the UTXO spending, or at least to my knowledge.

The security lies with the users themselves. It wouldn't matter if you were to lock your funds to certain addresses, hackers would just target those addresses instead. If you want to do this, then use a service that provides address whitelisting. For which, those services only locks the withdrawal on the surface and defeats normal client-side attacks but not server side attacks. When you're handing the control of your coins to any thirdparty, you'd have to be aware that they are controlling your funds.

It is valid. Due to the influx in transaction volume, the mempool size for Blockchain.info has presumably increased. As a result, the minimum fees for it to be entered into their mempool/block explorer has increased. They evicted your transaction from your mempool which isn't of any concern but it's wrong to display it as invalid.

If you do an RBF with sufficient fees, it will definitely be confirmed within a reasonable period of time. 1 satoshi/vbyte probably won't make the cut for a long time.

No. Electrum 3.3.3 and below were vulnerable to phishing attacks which would disguise it as Electrum updates. Don't trust anything that tells you to upgrade in the client.

Electrum clients below that version are mostly unable to connect to the server as people has done a DOS attack on them to prevent them to connect to malicious server. Go to Electrum.org, verify the files and install.

What's your Electrum version? Did you download from Electrum.org? There are plenty of phishing sites.

The most likely issue is with the server that you're using. Is the bubble at the bottom right green? Try pressing it, uncheck Select Server Automatically, right click on one of the servers and click Use as server.

That is the recommended way. I don't recommend anyone trying to extract their private keys either, if they're inexperienced. Synchronizing the Bitcoin Core with your wallet.dat properly is the only way to ensure that you have transferred out all your funds from the wallet properly. You can prune your Bitcoin Core to reduce the disk space requirements as well.

Malwares can steal your private keys, even if you don't dump your private keys. It is more than common. The only risky part is the fact that it is often stored within the clipboard for an extended period of time and someone else uses your computer and view your clipboard history, then you'll expose your entire private key. That and some people don't know how to use it properly.

You can create a new raw transaction that spends the inputs from your first transaction and thus doing an RBF on the first and invalidate all of the subsequent transactions.

Which is what we're concerned about. Let's say I have 100 addresses and I am cautious about spending their outputs separately. I don't want to link them all to a singular identity; I have used different pseudonyms across various services and I've used it to pay for anonymous hosting, used an exchange on one, etc etc. If my SPV wallet queries all of the addresses on the same server, there is a high chance that all of the queried addresses belongs to the same person and thus negating the benefits of me so cautiously segregating all of the addresses from each other.

Most people would not want anyone to be able to link a group of addresses together. That might not be your focus or definition of privacy but it certainly is for loads of people.

Here: https://docs.wasabiwallet.io/why-wasabi/NetworkLevelPrivacy.html#wasabi-s-solution. Not all SPV wallets are created equal.

That is correct. Transactions to an address that is in the same wallet shows up as N/A on the address column.
Not forever, likely just unconfirmed.
My guess is that what you've done is that you've spent the outputs of the first transaction in the second transaction. This means that your second transaction cannot be confirmed without the first transaction confirming. This is not an issue however. If you've signaled RBF, you can try to use abandon transaction as mentioned for both transaction and spend it again with a higher fee if it is not in your mempool and it likely is. 

I'm not sure if Bitcoin Core allows the RBF to have different outputs. IIRC, it doesn't so that could be a problem. Should try to create a raw transaction in that case, with care.
Zapwallettxes was removed in 0.21.0, just in case OP tries it.

Then you're just delusional. There is not guarantee that Bitcoin holds its value. Personally, I believe that it could be worth more than the value currently but I'm still classifying it in the smallest proportion of my investments. In case you've forgot, loans generally comes with a certain level of interest.
No. If you don't have the means to repay the loan if all the money that you put into Bitcoin turns into zero the next moment (well, even if you do, how would you feel is you're suddenly in a debt of $20K?) , then you shouldn't do it. Cryptos in general are highly volatile, endangering yourself with higher than necessary risk is not advisable.

It sounds about right.

One thing that I would do differently from steps 9 and 10 (and actually clarified in the notes) would be to not reconnect your computer after you have transferred your wallet.dat over and use the raw transaction method. Note that for partial synchronization to work, you'll have to be sure of the exact timeframe whereby you have received the Bitcoins and to synchronize after that. Any transactions done beyond that synchronization would not be shown and there is a risk that Bitcoin Core accidentally creates an invalid transaction, which is fine just a bit annoying; it wouldn't cause you to lose your funds.