It is not that the column is buggy, and TGDonovan has the correct track: the issue is that if Lacerte adds a form, they are likely adding it IN THE MIDDLE OF where other forms already exist.  So <the form that USED TO BE tracked in column '23'> is now shifted to the right, into column '24', and the NEW form just added is recorded in column 23.
  YES, this means that EVERYTHING downstream from 'column 23' is now incorrect.
  YES, this means that you have clients (who *did* have the previous 'form 23') recorded as having <whatever this new form is>, because it is recorded in 'column 23'.
  NO, if you re-process (including just going to Alt+F[orms view]) a Locked return, NOTHING WILL UPDATE (because 'locked').
  So YES, you have to do as TGDonovan did and UNlock all of your files, and re-process your entire data directory, to take into account the new form.
  (If you have a USE for having files locked, I highly recommend making a copy of your data directory [call it like "\FormMetrics\" or some such], and figuring out your form usage from there instead of your primary, 'live' data.)
  NO, none of this lasts through the time when Lacerte updates THE NEXT FORM, because that may well be now in "column 7" (so, even before this one that was added), and then the next time, "column 12" (in between them) before finally adding one down in "column 58".
  YES, you then have to re-duplicate your data directory and re-process your entire client list, yet again, for each of those releases.
  NO, this is not in fact an intelligent way to run a railroad.

.

As others have said, data table 6 is for the numbers themselves (what appears on the two-year comparison Tax Summary, which is fundamentally "most of the numbers from the 1040") and data table 7 is for the forms.  See above for "issues with dealing with forms".

For figuring out the forms...  look at "x:\##tax\option##\USforms.?W#" (where "?" is the module letter, and "#" is the terminal digit of the year, and "##" is the last TWO digits of the year); adjust for your own installation drive & pathing.
 - The file has the forms STORED in, I believe, the order in which a paper return is to be constructed.  (The small bold-face "Attachment Sequence Number" that the IRS uses in the top right corner.)
 - Each form has its variable number (left side), and its form referent (right side).  "60168=Form 5405"

 * After I solved this once to make my database show them to me in the correct order, I stopped thinking about it.  I may be mis-remembering how this works, because it was such a PITA to work with.

 - You need to sort them ALPHABETICALLY by variable number.  Note that "61" comes AFTER "60168" just displayed above, because "60 which happens to be followed by 168" is less than "61", alphabetically.
 - You need to FIND the one to use, by its column position.  YES, this means that "some of the first twenty that you see" may very well NOT BE IN THE FIRST TWENTY COLUMNS YOU DEAL WITH, because they sort (alphabetically by variable name) out to beyond what you can see right away.

So I am looking at my local machine current install (I may or may not have pulled all updates down from the Hosted environment yet), and I see that I am on the top-line version number (variable 0000) is 44.0125.  As we can see, "Form 1040" is #1661, and "1040-NR" is 19; "1040-X" is #588.
  The sorting order will be "1661, then 19, then 588."  If we add "Schedule A (Dis Std)"/238981 and "Schedule D"/2186 to the mix, they sort like this:
 1661
 19
 2186
 238981
 588
(Remember to sort ALPHABETICALLY.)

This means that "10429", which is "Form 8834", is actually THE FIRST FORM recorded in the data table.  1040 doesn't happen until 16th.

(While you are looking at these variables, I also highly recommend search-and-replace removing the word "Form " [including the space at the end], so that you get JUST the form # itself.
 * NOTE * that when you do that, you need to remember NOT TO CHANGE THE ACTUAL USFORMS FILE ITSELF; highlight/copy/paste your list of forms & variables, and work with them externally!)