I've introduced two changes to my process that so far seem to have resolved these issues.

Issue #1 - When a form is saved as a draft and re-opened, it doesn't display correctly.  This was because I am populating my forms (in one case a table, in another a collection) with the results of a series of database lookups - part of this process includes adding additional rows/records to the table/collection in which to display the database info; each time the window was loaded, it added more rows - got really messy...  To get around this, I added a check value to track whether the data was loaded.  In my Javascript that is called when the form loads, it checks for this check value, if it's not there, it proceeds with loading the form, and finishes by populating the check value.  Then the next time the form is saved as a draft and then re-opened, the check value is already there so it doesn't attempt to reload the values into the form.  Works beautifully.

Issue #2 - I wanted to ensure that multiple users couldn't be working on the same part of the form simultaneously.  This one required some tracking in my database.  My process starts with one form that gives several options, which lead into several different secondary forms, one for each of the options.  I'm fine with multiples of the first form, but I only want one instance of each of the secondary forms to be running at a time.  I added a table to my database with one record for each one of the secondary forms - each record had fields to track a username and a date.  When the first form is loaded, it checks this database table to see if each of the secondary forms' associated records have a name and date populated (or if they are null) - if they are null, it will display the options to access the forms, if they are not null, it will display a message that the process is already started, by which user, and on what date.  Then it was just a matter of adding two workflow processes, one that runs right after the first form, and populates into the database record the current date and the username of the form initiator.  The second workflow process is kicked off after any of the secondary forms are cancelled or submitted - this one will update the database record with null values.  The result is that once a user gets to one of the secondary forms, it has to be cancelled or submitted before any other process can move to that particular secondary form.  So far, this is working to prevent two users from accessing the same secondary form simultaneously.  In the end, I think it's actually pretty user-friendly (even if it wasn't very developer-friendly).