I enjoyed having the brief opportunity to take you under my wing when you were fresh out of college. You were a quick study so its no surprise that you would come up with a lot of good questions all pointing to the holes in my developer documentation .
Thanks for prodding me, I've taken a little time this morning to fill in some of those holes.
Question 1 Managing source control for your project while working with mojoportal from svn trunk:
I just created a page
with notes about that.
Question 2 Using the mojoPortal Installation with your own features.
I just created this documentation.
Question 3 Deployment
Some of this is covered in the above links and also in the existing deployment documentation. I don't understand what you mean about medium trust requiring separate copies. In medium trust you have to disable a few things and configure differently and delete a few dlls, notes on that here.
Question 4 Managing Skins
Skins are self contained in their own folders. As long as you give your skin folder a good unique name it is very unlikely that mojoportal skins will ever overwrite them. The library of skins avilable when creating new sites in an installation come from the /Data/skins folder and when the site is created they are copied to /Data/Sites/[SiteID]/skins and these are the ones actually used by the site. You can put your owns site specific custom ones here and they will not be avialble to other sites. Though a mojoportal skin does contain a theme.skin file I recommend you don't ever use that and stick with just css. Styling controls with ASP.NET themes causes a lot of bulky inline style to be rendered in the page and this hurts performance becaue bulkier pages are slower to load.
Question 5 Automated Process and long running tasks
Yes mojoportal does have a framework that makes it easier to build tasks that can run on background threads. I doubt if anyone else is using this as its not been documented until now, but I implemented it for sending emails to the newsletter subscribers. For a long list this task could take a while so it shouldn't run on the same thread as a web page because it will block until it finishes and this would create a bad UI experience. Instead wanted to queue the task on a new thread and allow the current thread to render the page.