to add to my article Avoid Primary Key-Assistant, here is a 4D iNug-statement of Keisuke Miyako from Mon, 20 Apr 2015 03:41:27

the v14 primary-check rule is as follows:

the engine scans all records on startup, when:

* a field is found in the structure file that does not exist in the data file, and
* that field is a primary key

as is the case with any newly added primary key, the engine will look for NULLs or duplicates.

since the field does not exist in the data file, they will be evaluated as NULL, according to standard 4D behaviour.

then, the engine will assign new values to the primary key field, if, and only if,

* the „auto-generate/auto-increment“ attribute is activated.

otherwise, the engine will not updated existing records, and as a consequence,

* journaling will be disabled for that table.

with that in mind, my answers to your question will be

Then, once these fields are created, is all I have to do is close the data
file and re-open it, and 4D will recognize that the field is unpopulated
and automatically assign values?

no, you should add your PKs using v14 and an empty data file, and then re-open your real data file with that modified structure file.

do I have to do anything special to force the population of the new primary key fields

basically you have two options:

add PKs in your v13 structure file, (preferably 13.5) using the v13 PK wizard component or SQL, and populate existing records by code.

ftp://ftp-public.4d.fr/Components/4Dv13/4Dv13_PK_Manager_Component/

add automatic PKs in your v14 structure file and an empty data file, using the PK wizard (now part of structure editor) or SQL,
then open your v13 data file with that structure file when you are ready to upgrade.
existing records will be populated automatically.

the first option allows you to deal with the issue of PKs prior to the actual upgrade.
the second option is much easier, but could be problematic if the data file is very large.

miyako

P.S.

Thomas Maul recommended using a LONGINT key, as it is
smaller. What confuses me is, „is UUID format mutually exclusive of a
LONGINT data type?“

I think his conclusion was that the size and speed difference was so negligible,
and that UUID was the preferred option.