- Am I right, is this a derivation path for a Bitcoin wallet that follows this standard?
Close. There is also an account level in between.
Also, there is no distinction between receive and change transactions. Generally, every transaction will have both receive and change outputs however. The difference is that the receive outputs are to addresses created by the recipient, and change outputs are back to the sender, and added by the sender software itself.
- Is this how BIP44 wallets search for funds? Those keys for which there are funds (UTXO) will save the rest just discard (for now)?
The first 43 hardened descendants of the root are not discarded typically; they're just never computed. You can immediately compute hardened child 44' from the root without computing the other ones. See BIP32 for details.
Also, BIP44 doesn't really specify how a wallet should work; it just defines what its keys are.
- By BIP44 keys are always non-hardened?
The last derivation step is non-hardened. The first three derivation steps from the root are hardened, however.
- Number of keys defined by BIP44 is 2 * 2^31? (main question)
Per account, yes; 231 internal (change) ones and 231 external (receive) ones. Given that in all of Bitcoin's history there have been less than 230 transactions in total, that ought to be sufficient for a single wallet. BIP44 also supports multiple accounts, which each have this many numbers. Further, nothing prevents wallet from supporting more keys than just the BIP44 ones.
- Is the property of extended public keys for address_index keys "invalidated" by using this standard?
I'm not sure I understand your question. If you have the xpub corresponding to the m / 44' / 0' / 0' node you can compute all leaf public keys under it (so all keys for both internal and external). If you only have the xpub for m or m / 44', that is worthless as you need the private key too to compute hardened descendants.
