Standardize field names for contact api

for the most part the new apis are great in following naming conventions, which makes individual_prefix and individual_suffix stick out even more like sore thumbs.
a call to civicrm_api('contact', 'get', $params);
will return an array like this:

contact_id (String, 1 characters ) 1
contact_type (String, 10 characters ) Individual
sort_name (String, 14 characters ) Watts, Coleman
display_name (String, 20 characters ) Mr. Coleman Watts IV
do_not_email (String, 1 characters ) 0
do_not_phone (String, 1 characters ) 0
do_not_mail (String, 1 characters ) 0
do_not_sms (String, 1 characters ) 0
do_not_trade (String, 1 characters ) 0
is_opt_out (String, 1 characters ) 0
preferred_mail_format (String, 4 characters ) Both
first_name (String, 7 characters ) Coleman
last_name (String, 5 characters ) Watts
is_deceased (String, 1 characters ) 0
contact_is_deleted (String, 1 characters ) 0
individual_prefix_id (String, 1 characters ) 3
individual_prefix (String, 3 characters ) Mr.
individual_suffix_id (String, 1 characters ) 5
individual_suffix (String, 2 characters ) IV
address_id (String, 1 characters ) 2
street_address (String, 16 characters ) 13075 Woolman Ln
city (String, 11 characters ) Nevada City
postal_code (String, 5 characters ) 95959
state_province_id (String, 4 characters ) 1004
state_province_name (String, 10 characters ) California
state_province (String, 2 characters ) CA
country_id (String, 4 characters ) 1228
country (String, 13 characters ) United States
phone_id (String, 1 characters ) 2
phone_type_id (String, 1 characters ) 1
phone (String, 8 characters ) 555-5555
email_id (String, 1 characters ) 2
email (String, 23 characters ) admin@test.com
on_hold (String, 1 characters ) 0
worldregion_id (String, 1 characters ) 2
world_region (String, 43 characters ) America South, Central, North and Caribbean

Note that every single array key corresponds exactly with the column names in the database, except for those pesky prefixes and suffixes. Why their names have been changed I can't imagine, but this kind of irregularity makes programmatic implementations of the api unnecessarily difficult.
I tried to investigate why this was happening but didn't manage to get all the way down the rabbit hole. I'd be happy to work with someone on irc to try and get it solved though, fixing this before the release of 4.0/3.4 would be way better than trying to do it afterwards.