In fle_stats.cpp, each incrementXCount() function calls registerCollectionStats(), which does getOrEmplace(nss, ...). That means every operation creates a map entry if one doesn't exist yet. Both inputs come straight from the request:

• nss is the request's namespace.
• efc is parsed from the client-supplied encryptionInformation.

The only code that ever removes an entry is deregisterCollectionStats, and it runs only from the collection catalog when a real encrypted collection is dropped. Those two paths don't match up, which leads to three problems:

1. Any namespace creates a permanent entry. A user with find (or insert, update, delete) rights on a database can send QE-shaped commands against db.c1, db.c2, … db.cN. The collections don't need to exist or be encrypted; the request just needs an encryptionInformation schema for that namespace, which is what getAndValidateSchema checks. The metric is bumped before the transaction runs, so the entry is created even if the operation then fails. Nothing on the catalog side will ever deregister it, so memory grows with the number of distinct names sent.
2. On mongos, nothing is ever removed. processFLEFindS in src/mongo/db/fle_crud.cpp:2021 and the mongos write paths also end up in these increments. mongos has no local collection catalog, so no deregister call ever happens there. Every namespace ever queried through a router stays in the map for the life of the process, even for legitimate collections that were later dropped.
3. A drop racing with an in-flight operation brings the entry back. If an operation's increment runs just after a drop's erase, getOrEmplace recreates the entry. Since the collection is gone, it will never be deregistered again. The counts that operation adds after the drop are missing from _deletedCollStats for good.