Not sure if this is useful. Otherwise you could also create a "default from node" for sendrawtransaction or other RPCs. However, this will make tests harder to read and understand, as it is unclear which node the tx was sent from.

The MiniWallet acts as a shared wallet between all nodes spun up in the test (as opposed to a wallet that is attached and managed by a specific node).

I think the only place where this makes sense is for tests that only spin up one node.

@MarcoFalke: Fair points, though I would counter the general "will make tests harder to read and understand" argument with the fact that for the vast majority of tests the origin of a tx is not relevant at all, as we just want to fill the mempools of all nodes (in the rare cases where different mempool- or policy-related settings are used, or the nodes are not all connected, from_node could still be passed explicitly). In a personal experience it feels odd to already need to pass a specific node on the MiniWallet instance but then still having to pass from_node again and again for trivial tests.

As a possibly less controversial suggestion, would it at least make sense to introduce the default parameter for create_self_transfer? The node parameter is only used for the testmempoolaccept RPC and the tx is not sent yet, i.e. using self._test_node as default for that purpose seems to be fine. send_self_transfer and send_to would of course still call create_self_transfer with the still mandatory from_node argument.

want to fill the mempools of all nodes

Ok, unrelated, but I think we should make that explicit. Not sure how successful such a patch would be, considering that #23300 took two years (#20362). But overall we should be moving into that direction, given that racy tests will inevitably lead to bugs (#22437 (comment)).

less controversial

Yeah, should be uncontroversial

Closing this now, as there are good arguments against it and it's very unlikely to get merged; #24035 includes a stripped-down variant of this PR that only changes create_self_transfer (commit fb26175).

As I raised the same issue on #25435 (comment) and without being aware of this PR, I'll reply here, as a more suitable discussion thread.

In a personal experience it feels odd to already need to pass a specific node on the MiniWallet instance but then still having to pass from_node again and again for trivial tests

After #25435 there will be no usage of test_node in the MiniWallet logic, so one approach that will also make clear that "The MiniWallet acts as a shared wallet between all nodes spun up in the test" could be to remove the test_node argument. Therefore having the shared wallet and from_node indicating the node that each tx is send.
EDIT: NOT TRUE

I think it can be done by explicitly passing a default_send_node to MiniWallet, with the disclaimer that it should only be used where no ambiguity exists. For example, for tests that only have one node? (src)

That would make sense. I was thinking that a way to be sure that this is used where no ambiguity exists could be the introduction of a use_miniwallet set_test_param that will create an instance of the MiniWallet that will only have a default_send_node when there is only one node. This will also allow for one less import on each test file that is using the MiniWallet. However, this approach has an issue as it does not take into consideration the different modes that the MiniWallet can have.

After #25435 there will be no usage of test_node in the MiniWallet logic

I don't think this is true. Those will remain:

test/functional/test_framework/wallet.py:            self._scriptPubKey = bytes.fromhex(self._test_node.validateaddress(self._address)['scriptPubKey'])
test/functional/test_framework/wallet.py:        res = self._test_node.scantxoutset(action="start", scanobjects=[self.get_descriptor()])
test/functional/test_framework/wallet.py:        blocks = self._test_node.generatetodescriptor(num_blocks, self.get_descriptor(), **kwargs)
test/functional/test_framework/wallet.py:            block_info = self._test_node.getblock(blockhash=b, verbosity=2)

I don't think this is true. Those will remain:

Yes, I'm not sure what I was thinking😅