Yeah, track_orders() code is not super easy to grasp so I'll see if this might help ...
The condition you mentioned is just a way to make the whole thing portable, that line winds up being run 390 times a day throughout the backtest (or live) and is only true the first time, where c is the shortcut name being used for context and context.trac is the variable used to store order id's, like c.trac[o.id]. Initially the id is added when an order has been created, and then after that minute the order is checked for fills at o = get_order(oid), and deleted when complete. That line
if 'trac' not in c: could have looked for t_options or t_dates instead of trac to find out if they had been initialized yet. As mentioned, one can Move these to initialize() for better efficiency so the check does not need to run 390 times a day. And the import also, can go to the top with any other imports.
The lack of double logging is a key question. An order can sit unfilled for most of the day and the only times there will be logging are when the order has first been created and also when any part of the order is filled and to indicate when done. So track_orders() can be called many times in a row, even many times in the same minute and any activity on an order only registers the first time that change happens because the previous o.filled is stored in c.trac[o.id]['amnt']. The letter 'o' stands for order and order ids (o.id) are unique since they are keys in a dictionary.
Part of the question is that one might wonder, since this is called out of handle_data every minute, then why the need to also make the call to it from one's own functions after any ordering?
The answer is because handle_data is processed at the beginning of each minute while scheduled functions run at the end of every minute so an order placed out of a scheduled function such as trade() for example in one minute (would be at the end of that minute) and can be completely filled and gone from the get_open_orders() radar by the time the next minute rolls around. Orders would be missed by this tool if being called only from handle_data. The need to call track_orders() after any orders from within the functions where the orders are made is so the second of the two main blocks of code, the one marked 'Handle new orders', can become aware of each order created and store its id as c.trac[o.id]. there is a way that might be considered better, scheduling every minute in a loop
Mess around with this backtest, inject prints statements or use the debugger and you'll eventually trust the code pretty well. Logging output is pasted at the bottom in the 'Source Code' tab for convenience to those just passing by.