Once you switch to Simple the Trans Log will no longer maintain a log of operations since your last (database files) backup - at the point of the switch all transactions will have been committed to the main database files so will not be discarded - they are already effective in the database files.
Your point 1 is not (in my opinion) worth doing - once switched to SIMPLE, you should backup the Database files - which will contain all data.
Remember that the FULL recovery model only exists so that you don't have to backup the database files every time (so in FULL recovery model your recovery process is: Restore Main Database files, then Restore Transaction Log Backups). With the SIMPLE model the recovery process is only Restore Main Database files.
What I'm trying to say is: As quickly as possible (depending on performance and the type of transaction) the transactions that can be found in the Transaction Log are Committed to the Main Data files (mdf, ndf) which are stored in the .bak file when Backed up.
So SIMPLE model allows you to restore to the point in time when you took a .bak
FULL model allows you to restore to the point in time when you last took a .trn (transaction log backup) - in the case of multiple trn backups that would be a restore of Bak + trn + trn + trn (if you had taken 3 trn backups since your last bak).
The only purpose of the differing recovery models is backup strategy and time saved by not taking a bak every time.
Now I've typed it out, I see why you've asked the question!
Although not perfect English, I think this gives a relatively good breakdown of the different models and why you'd use them: http://www.todo-backup.com/backup-resource/sql-backup-software/three-sql-server-recovery-models.htm
This is how I would do your list:
- Switch to simple.
- Perform full backup of data files (.bak)
- Possibly run DBCC SHRINKFILE with TRUNCATE ONLY to free up some disk space.
- Possibly alter the database to decrease the trans log file size.
- Perform a full backup.
- Switch to full (I assume you're switching back!??!)
Notes: If you're worried, then do a Backup before 1 as well. I'll leave 3 and 4 as they are, because they're a whole different question! (http://www.sqlskills.com/blogs/paul/why-you-should-not-shrink-your-data-files/)