It's gratifying to know that someone is interested in the technical details we describe in our texts 
This is a simple but crucial part of security.
From our "tests" we haven't found any project that has thought about this feature.
Probably, this feature isn't implemented due to specific 'technical challenges,' like using addresses from different wallets at the same time when creating transactions.
However, we've fully implemented this feature.
In short, we regularly switch wallets.
Everything happens automatically. For example, today deposit addresses come from wallet1, and change also goes to wallet1. Tomorrow, deposit addresses come from wallet2, and change also goes to wallet2. When all addresses from wallet1 are used, we remove that wallet.
Quote
Is this talking just about the website/database, or does this claim also extend to the Bitcoin node(s) being used to run the service? As deleting individual addresses from the wallet.dat in the Bitcoin node has been reported to be not possible on a command-line/operational level, you would need to delete the wallet every time and restart the node, which would be seemingly infeasible for a mixer/tumbler to achieve as this would cause constant node disruption...Unless tumbler.io can additionally claim to have also created a way to create/delete wallets automatically within the node without disrupting system operation?
This is a simple but crucial part of security.
From our "tests" we haven't found any project that has thought about this feature.
Probably, this feature isn't implemented due to specific 'technical challenges,' like using addresses from different wallets at the same time when creating transactions.
However, we've fully implemented this feature.
In short, we regularly switch wallets.
Everything happens automatically. For example, today deposit addresses come from wallet1, and change also goes to wallet1. Tomorrow, deposit addresses come from wallet2, and change also goes to wallet2. When all addresses from wallet1 are used, we remove that wallet.
I completely agree, I haven't seen any mixer claim it just yet or else I believe I'd have asked the same question. If so, it has gone over my head or there were more pressing things to ask about them.
p.s
This part is also crucial because without the ability to use addresses from different wallets when forming transactions, we wouldn't be able to fully implement transaction generation based on Blockchair patterns.
This was easily noticeable during tests when transactions described by our testers were formed using addresses of different types. At that moment, we simply took addresses from different wallets.
example
out | in
3.... | bc1..
bc1.. | client
bc1.. | 3..
This part is also crucial because without the ability to use addresses from different wallets when forming transactions, we wouldn't be able to fully implement transaction generation based on Blockchair patterns.
This was easily noticeable during tests when transactions described by our testers were formed using addresses of different types. At that moment, we simply took addresses from different wallets.
example
out | in
3.... | bc1..
bc1.. | client
bc1.. | 3..
This is on the money as well. Great job, truly. Your answers makes perfect sense and there isn't much for me to come back. You have shown a good example of the careful crafting that is behind the sleek front-end with your explanation, kudos to both the work and the response, and I look forward to testing the service further in the future!