regarding 1.) At the moment we start at a milestone that is "n" milestones in the past (relative to the latest solid milestone) so it is deterministic where we start the random walk. The depth parameter can directly be controlled in the API call "getTransactionsToApprove" (see https://iota.readme.io/reference#gettransactionstoapprove).
It should be bigger than 15 to reach a good randomness. The deeper you go the more potential paths exist that you can take - so a deeper depth is usually better for the tangle.
This means you will see the transactions in the order that you attached them to the tangle. Assuming that you attached them in the correct order, you will "walk" through them in the correct order. It is of course possible that you will arrive at a later spend through the 2nd path (branch vs trunk) and therefore skip the previous spend but this "problem" also exists with the remainder approach where you might skip the transaction that funds the remainder address. In this case the 2nd spend would be considered invalid (the same way as the spend from an unprocessed remainder address would be considered invalid).
Whenever we face an invalid transaction we apply a backtracking strategy and try another path (until we find 2 valid tips).
regarding 2.) Since it is possible that we "skip" transactions (due to the fact that there are usually 2 path that exist to arrive at any given point), they are only in partial order.
If you would set the "trunk" to be the same transaction as the "branch", you could prevent the possibility of reaching the 2nd spend without having walked through the first one but that would also decrease the chances of your transaction to be reached.
Since we plan to only sweep the balances every now and then (wallets could implement sth like only sweep if your last sweep is not older than n minutes) this is something that can be worked around to be practically irrelevant.