We have an obsolete comment in api.h that says:

 * In almost all cases, API_END is returning immediately, make it simple.
 * If a session or connection method is about to return WT_NOTFOUND (some
 * underlying object was not found), map it to ENOENT, only cursor methods
 * return WT_NOTFOUND.

That isn't how we're using API_END_RET vs API_END_RET_NOTFOUND_MAP. The latter should be used to map a WT_NOTFOUND from a handle cache lookup or metadata read to ENOENT, indicating that some requested URI does not exist. Some non-cursor calls explicitly expect to return WT_NOTFOUND (e.g., WT_CONNECTION::query_timestamp).

For calls where WT_NOTFOUND is not expected, mapping it to ENOENT doesn't make anything better. Review the use of these macros, fix the comment and consider adding new versions to make it clear which one to use.

In particular, API_END_RET should be the common case: potentially it could assert that ret != WT_NOTFOUND, then we could have API_END_RET_NOTFOUND_OK for methods that are expected to return WT_NOTFOUND, and limit API_END_RET_NOTFOUND_MAP to methods that look up URIs.