NIT

I completely disagree, if distance will do for each, I want instead of this code will be written ++stale in cycle above

Because this thread executes the deletion at some point after the user issued a db._dropDatabase() call.
Consider the following situation:

• user executes db._dropDatabase("foo");
• user executes db._createDatabase("foo");
• DatabaseManagerThread now finds the deleted database "foo". Shall it remove its application directory now? We cannot be sure about it, because it may be the new database's application directory.

I understand, but we use id for new databases in path for v8 stuff (query register still use name :()

We unfortunately use the database name for the Foxx app directories.

Not always, please check following code

/// @brief return either the name of the database to be used as a folder name,
/// or its id if its name contains special characters and is not fully supported
/// in every OS
[[nodiscard]] static std::string_view getDatabaseDirName(std::string_view name,
                                                         std::string_view id) {
  bool const isOldStyleName = DatabaseNameValidator::isAllowedName(
      /*allowSystem=*/true, /*extendedNames=*/false, name);
  return (isOldStyleName || id.empty()) ? name : id;
}

Why is the memory order acquire here and not release?

Because we probably want to synchronize with markAsDropped (if don't want should be relaxed), and our +2 not needed for synchronization code.

You can look on intrusive_ptr as an a good example of this pattern
https://www.boost.org/doc/libs/1_81_0/libs/atomic/doc/html/atomic/usage_examples.html#boost_atomic.usage_examples.example_reference_counters

For -2 we need release because we want to synchronize with isDangling

Should it be memory order release here?

Not

I think this could be a behavior change and may be unsafe.
It someone manages to set the drop bit on the system database, this function will now return true, but previously it always returned false. It could have unintended side-effects for example in the DatabaseManagerThread, which will remove the database then if this function here returns true.
ofc it would be useful to not allow to set the drop bit for the system database in the first place, but this function here previously provided some extra security.

No, please see assert in markAsDropped.
System database is never isDropped, so it's never isDangling

I guess ASSERT than should be our choice. As system database should never have delete bit set.