I’ve discovered that if you set $db_persist = 1 in Settings.php, it seems to prevents the "smf_sessions table does not exist" error. You can repeat the error by accessing yoursite.com/uri_to_smf/ directly. If you request it again, it seems to work fine. To repeat, just delete the session cookies (helpful if you have FF and the Web Developer extension) and request it again.
I’m not exactly sure why, although it seems to be related to the db_query function (Subs.php) and how the db_connection is possibly cached from MODX and being "piggybacked" by SMF so that if you have the same db/user/pw on the same host, SMF might be "hijacking" a persisted MODX session. However, this is unconfirmed speculation -- I’m too nauseous from sifting through the awful SMF code to go any further without first taking a Gravol.
As for the login synch prob I reported, since being sidetracked with the smf_sessions table error, I have not tried to reproduce it. I did just notice that you can set the login duration on the modxcms.com forum and since they’re using SMF, I should be able to remove that option from the user interface and set it to be the same as the modx session ("forever"). However, I’m not sure if the forum session is set once the user requests /forums/index.php or if both sessions are set when the user logs in to modx. If it’s not really set until they request the forum page, then it will never be in synch (for instance a user could login to the modx site and wait 20 minutes before going to the forums).
<rant>What some bright spark needs to create is a forum library ala PEAR or whatever -- just a transparent API of function calls to handle the basic forum threading -- instead of all these nasty, brittle synch hacks. I’m not trying to diss SMF Integration’s efforts -- its actually one of the better ones I’ve seen and a necessary evil, unfortunately -- but it shouldn’t have to be this way. Nobody thinks of interop; it’s like these forum and gallery developers are living in their own little worlds. </rant>