I think populate works as follows:
First principle. MyLog records the details of an aircraft as they were when the aircraft was first logged. So, if AT was "..." when the aircraft was first received, it will stay as "..." for ever. Populate will NOT overwrite data.
The exception is blank fields. So, if AT was blank when the aircraft was first received, it will be recorded as blank. If, at a later date, you update Navdata with a corrected AT (eg. "A388"), then populate will fill in the blanks.
For aircraft where the registration is unknown, nothing is recorded in Navdata. Everytime you then receive that aircraft, or run populate, RB will attempt to get details from the Airnav server, and put the details in Navdata. When you next run populate, these details will update the aircraft in Mylog.
IMO, there are two "issues" with this approach.
1. Aircraft in RB are "keyed" on the ModeS code. So, if an aircraft changes registration but keeps the same ModeS code, the database can't really handle this situation. So, RB keeps the old registration details. Ideally, you would want a new MyLog entry created for the new registration, but keep the old one as well.
2. Airnav (or their data provider) need to stop putting "..." in the AT field when the aircraft type is unknown. If it was left blank instead, populate would be able to update it.
HOWEVER, I'm not a great user of the MyLog function, so I'm not a great expert on the way it works.