Perhaps the most egregious part of a MARC record is its control (or fixed) fields. Fixed fields were designed to compactly store information believed to be fairly static. Because they often rely on byte positions, they, more than any other part of the MARC standard, have had difficulty adapting to change.
For instance, all of you will remember the Y2K scare a couple of years ago. Did you know there is insufficient space in the 008 control field to handle Y2K years without redefining all the subsequent bytes? This is just one example of how relying on byte position to define data should be a thing of the past.
Another example of the problem with using control fields is the myriad of record formats that must be accommodated by bytes six and seven of the leader and, as a result of format integration, in the multiply occurring, fixed length, 006 control field.
If this wasn't confusing enough, other fixed-field byte values vary depending on the conditionally determined format of the record.
For example, byte 34 in a book record's 008 control field describes a type of biography; that same byte in a serial record indicates the record's entry convention; in a visual materials record, byte 34 indicates the material's creation technique.
This kind of complexity makes perfect sense if the format is just intended to transfer the data from one machine to another, each then transforming the data into its own proprietary internal format.
In the Internet age, however, where humans interact with data and data processing is modularized and distributed, using an efficient format that gets its efficiency by sacrificing re-usability doesn't make sense.