I understand how the EBUSY is getting generated. I was on a wrong path thinking it was a barrier/publish issue because the connection was closed and reopened, resetting the txn_global values. Once I added a bit more debugging I saw that. Anyway, the drop file is racing with the eviction thread. The sequence of events:
In txn_global, oldest_id is 1875, last_running is 1875, current is 1976.
DROP: Call wt_txn_update_oldest from wt_evict_file.
DROP: In wt_txn_update_oldest set txn_global->scan_count to 1.
EVICT: Calls wt_txn_update_oldest from wt_evict_lru.
EVICT: In wt_txn_update_oldest set txn_global->scan_count to 2.
DROP: Immediately returns from wt_txn_update_oldest (due to atomic cas of scan_count indicating a race) and ends up in rec_txn_read.
DROP: rec_txn_read calls wt_txn_committed in the loop walking the upd_list and sees 1875 versus 1976, sets skipped.
DROP: rec_txn_read returns EBUSY at line 1190.
EVICT: Updates txn_global oldest_id and last_running to 1976.