Adding new fields to existing tables

Progress 11.1

I've got a development database , and have just added two new fields to a table.

The highest field-rpos in the table was 89.

Field1 got a field-rpos of 90

Field2 got a field-rpos of 71

This will cause existing r-code to fail with a crc-check.

Note: OE00149133    Type: Behavior Change
CRC check relaxed for r-code
---------------------------------
In previous OpenEdge versions, after a field is added to a table, any r-code
compiled against the old version of the table will not run, because the CRC in
the r-code is different from the CRC in the schema. 

For 10.1C, the CRC check is relaxed in some instances. If the change to a table
is a simple addition of one or more new fields, the old r-code will still
execute, even though the CRCs no longer match. When the CRCs do not match, the
AVM tests whether the fields of the table (specifically, their names, data
types, extents, and logical field record positions) have changed since the
r-code was compiled. If they have not changed, the old r-code should run. One
case where it will not run is if one of the new fields has a logical field record position less than one of the old fields (in other words, a new field has been inserted into the logical record position sequence).

See the highlight text above. One field is higher than the existing. All well and good. The second field has been inserted into the logical record position sequence. Boom. crc error.

My question is - why doesn't a new field *always* get a field-rpos higher than any existing field to avoid crc problems in the first place. This is simply ridiculous.

At least this is a development database. I can manually fix the _field-rpos of the field so that when I create an incremental .df it will be loaded into the target database with an appropriate _field-rpos.

Anyone got a good reason for this behaviour ?