Currently, a cursor that is duplicated via the WT_SESSION->open_cursor call takes the 'slow path' in opening. There's probably no reason that it can't take the fast path, that is, look for a matching cursor in the cache. The lookup will be fast, since we already have the hash value of the uri in the cursor to be duplicated.

A bad side effect of the current implementation can be seen in this access pattern:

c1 = session.open_cursor("file:a", None)
c2 = session.open_cursor(None, c1); # dup
c2.close();
c1.close();
...
c3 = session.open_cursor("file:a", None)
c4 = session.open_cursor(None, c4); # dup
c4.close();
c3.close();

c3 will reuse c1. We would expect that c4 would reuse c2, but since it takes the slow path, it won't. If this pattern is repeated again and again, additional cursors will be created, cached, but not reused (unless/until there is a change to the pattern than opens the uri explicitly more times). And as long as the data handle is open, the additional cursors sit in the cache, they won't be swept.