I've never encountered this behavior, but then I try real hard not to define tables with such a large number of fields either. You might consider making your 200+ item checklist a related table where you make each item a separate record instead of having a separate field for each.
"Since you can't put over 200 fields on a table I have had to make two tables, related to each other with an "Event ID" to complete the relationship"
You don't actually need two related tables like this. You can simply set up two or more layouts for the same table and put different sub sets of your fields on each layout.
There are a few tests you can try:
Create a completely new layout and add your checkbox fields to it and see if you get the same behavior.
Try duplicating your layout, delete some of the first added fields from the layout and see if the behavior/format of newly added fields change. Add a new field and see what it does...
Phil, I appreciate your response. The goal of this project is to have everything on 1 layout, then you can stick in the corner of one of our monitors and reference. The checklist is used to keep track of sequenced events like ACH batch files (money files) and Posting files (where money goes) that take place though the day on the ACH Network. The specific tasks are my fields and the current date represents each record. Looking back you would be able to tell which sequenced happened and which did not. In reading your response to the post I commented on I went to add a field to my layout and it worked correctly. I think it must be a formatting issue. I meant to say table view.
You can get what you describe while still using a table of related check box items. This would offer quite a bit more flexibility, though it does require a bit more work setting up the layout so that the related records form a row instead of a column. (You can use a horizontal portal trick to get that.)