Airline system changes are near the top or at the top for failed IT projects across the whole industry. A lot of that has to do with the legacy components that are necessary to maintain compatibility with 50 year old technologies and protocols (much dependent on the limit, of for example 2 characters in a field of a fixed mainframe record size). To remove these limits either requires not participating in standard ticketing (such as is done by ULCCs, so interline and codeshare are not generally possible) or a complete revamp of ticketing across all airlines, as IATA and others have been trying to do for decades.

What some people perceive as "why don't you have this simple function?" is often unfortunately a massive undertaking. One of the biggest ones of the lot is the hoops that have to be jumped through to accept more than 2 forms of payment and the change and cancel related to that limit when funds have to be reinstated, especially around split payments that have a payment component that has expiry rules and transaction cost due to the change. The 2 forms of payment limit is due to the ticket coding of the payment type, bearing in mind all standard tickets are still just an electronic facade of a physical multilayer paper ticket printed on a dot matrix printer. The complex business rules for this can be automated to some degree, but it is often better to just have a human deal with it (sometimes it looks automated, but actually just goes into an electronic queue for a human to deal with, especially for flight equipment changes, for example). The inconsistencies that sometimes happen after a change are usually caused by the myriad of edge cases in the business rules that are either not correctly implemented or tested.

My IT experiences in being involved in complex systems across many industries all indicate the airline industry is definitely the top of the problem pile for legacy systems interoperability issues due to the nature of inter-airline data interchange.