It is generally not safe to actively use multiple WT sessions from a single thread.  For example, if a thread has an open transaction on Session1, it should not make WT calls with Session2.  This can lead to deadlock or cache stuck.

These issues can be hard to detect in a complex application.  See, for example, SERVER-51281. To facilitate debugging such issues, WT could implement some sanity checking in diagnostic mode.  

One way to do this might be to maintain a table mapping threadIDs to the last session used by the thread.  On a new API call, WT would check the calling thread's entry in this table and return/log an error if it corresponds to a session with an active transaction that is different than one in the call.

There are probably smarter ways to accomplish this.