Can't tell anything from that image. A complete image that included the header might have shown a clue--such as showing that the fields that can't be edited are from a related table or something.
There are at several ways that come to mind that might keep a field in your table view from being editable:
a) It's a calculation field and thus cannot be edited under any circumstances
b) It's from a related table occurrence and there is no related record (and "allow creation.." is not enabled) linked to the current record on your layout.
c) The field has been added to the layout while in layout mode and browse mode access has been blocked.
d) The field has been added to the layout and a script trigger specified for the field that is performing a script that blocks access or editing on the field.
Here it is with header, just to prove none of these are from a related table: http://i.imgur.com/Hz0djoC.png
The only field here I'd consider "weird" is the a1 field, which is literally just a global 1 used for a few shortcuts.
In response to your lettered theories:
a) None of the pictured fields are calculation; there's only one calculation on this particular table, and I hid that field.
b) Obviously, these aren't related fields, as seen by the field names in my updated pic not having the format "table::field".
c) Hmm... I thought at least the old fields here (I can't even edit Serial Number, the cut-off field on the far left, which was the first field I made for this db) were created in table view, long before I began work on layout mode. But this sounds like a possibility; many of these fields *are* blocked from editing on the layout in browse mode in one of their occurrences, because I have 2 tabs on the actual form: one for viewing data, where all the fields are locked, and one for editing, where I can freely edit them. It's also worth noting that not one of the fields I've shown can be edited (a1, Notes, Sold Date, Sold Invoice) appear in the "locked" section of the form. This also applies to the editable fields in my other tables (including my non-layout tables being completely editable), with one exception: there is another "notes" field that can be edited from Table View, but appears on both tabs of its layout (though it's highly probable it was just in edit first and got it's locked form added to the other tab later). Assuming this *is* the issue, is there an easy fix, or am I going to just have to recreate the layouts with the "Editable" fields being made first?
d) I don't think this applies, but there is a script that runs whenever a field is committed which "updates" the a1 field with a 1, intended to keep calculation fields relying on Get(CurrentDate) accurate. I'd think I could at least click into the field if that was an issue, though, since the script doesn't run until commit.
c) Blocking browse mode access is layout specific. You'll need to enter layout mode and check for fields present on the layout while in layout mode to see if this is possible.
d) I considered this option highly unlikely, but since it is possible, I included it as the last one on the list.
An additional possibility is that your layout is damaged and it (or the file) should be replaced.
Found the actual answer to why the fields were locking (it was related to c, but that wasn't the whole picture). When a field appears twice in a layout, FileMaker apparently decides which iteration of the field to use to determine editability by judging which appears "first" (above and/or to the left of the other iteration, this ignores tabs) in the layout. So to fix the issue I had to reposition the Info tab stuff a small bit down and to the right, and the Edit tab up and to the left.
It feels like it would be better usability-wise if there was a checkbox in Field Options which determines table view enterability rather than something as trivial as layout positioning, but at least now I know how FileMaker currently determines this (and why the issue arose; I had previously rearranged the two tabs to "mirror" each other better, and the layout positioning differed by just a few pixels). I was worried that the file *was* damaged, so I'm glad this was at least under my control, even if the solution wasn't exactly well documented or ideal.
Edit: Ooh, this allows drop-down lists from table view too (At quick glance, seems to be grabbing all of the Data tab stuff from the Inspector), awesome! Guess I'll have to pay better attention to my positioning in my layouts from now on so Table View can use functions like this.
And why did you need two copies of the field on the layout when you are using table view to view the data anyway? Why not just remove the redundant copy of the field?