So, just a quick update. There are 2 sections that contain information on the basis set functions (per species): x_fhi_aims_section_controlIn_basis_set.x_fhi_aims_section_control**In**_basis_func and x_fhi_aims_section_controlInOut_atom_species.x_fhi_aims_section_control**InOut**_basis_func.

Firstly, one comes from the repetition of the raw settings read from the input file (control.in), while the other has an output summary (aims.out) - as interpreted by aims - of the input.
Generally, I abhor parsing the input file (or its repetition in the output file), unless information is missing. This does not seem to be a problem, as the output summary is quite verbose, stating all the major parameters, as well as, the orbitals. The only missing piece of information would be the divisions. I'm looking into how relevant this parameter is.

Secondly, the same information should never be repeated. I would relegate the orbitals used to the basis function section and only reference to the matching parameter settings.

Firstly, one contains raw information read from the input file (control.in), while the other has an output summary (aims.out) - as interpreted by aims - of the input.

On the first point made above, both sections do not necessarily report the same orbitals. The example in the issue description is indicative of this: the ion_occ lines were not picked up on, despite being uncommented. The reasons behind it are unclear, though there are counter-examples where everything works out fine, though (have one in a private collection). This builds on the case for only parsing the output file.

the ion_occ lines were not picked up on, despite being uncommented

According to one user, it could have something to do with the oxidation state of the atoms, triggering when an element is sufficiently oxidized. Indeed, ion_occ are lower orbitals (according to Hund's rule) than valence_occ and seem to act as a restriction on how much can be oxidized.

From correspondence with a FHI-aims dev, it was clarified that the ionic radii are only called when set in the tier section below.
Due to completeness of information and the opportunity to parse control.in files directly, we decided on parsing input and not interpreted input. Unused radial types will be left out of the tier section.