Rows and cols of tablefield is restricted by the saved data of a field which conflicts with default values

My use case:

Step 1: I have a tablefield defined with 2 columns and 9 rows where the top row is the header and the first column has defined default values, therefore presenting the end user with the ability to enter values for those pre-defined options:

(ignore the third column in the above image, as it shouldn't be there for the purposes of this example)

Step 2: As a regular user: I edit this field (wherever it may be- user/node etc.) and save my entries in the second column. So far so good.

Step 3: As an admin: I then go to edit the field settings (for the tablefield created in Step 1) to add another default value in the first column (by rebuilding the table with an additional row and entering the default value in column 1, row 10) and save the form.

Step 4: As a regular user: I return to edit the field and I can't see the newly created default value in column 1, row 10, because the widget form is 'rationalized' from the saved data. From this unserialized/rationalised data, the number of rows and columns are calculated for rebuilding the form.

This is not always the intended behaviour, especially when the rebuild table options are set to be excluded for the end user.

Therefore, my workaround is to provide a instance level option to allow site builders to say whether the values for cols/rows defined in the default value should always be respected. On the field settings form it looks like this:

When the widget form gets built, and this option is set, then the rows/cols values (part of the default values rebuild options in the field settings form) get used as the basis for the size of the tablefield to build.

This works for my use case, but will likely still need to be tested in the cases of ajax, field collection and the other more advanced use cases this module should support. I'm putting this out there for feedback and review. Marking as feature request, as this may not technically be a bug in what the intended functionality has been to date. That said, it causes issues with my use case, which may not be all that common. It would be good to know if anyone else has come across this quirk of the module to date. I couldn't find any directly related issues in the queue.

Patch to follow.