There were several reasons for the initial change, all a result of the complex changing of fields Artist, Genre, etc. from simple string fields to list fields. This created conflicts for some people and for MC itself under certain circumstances.
For example, [Genre] is typically thought of as being singular for music. And some people use file location rules to organize their music, based on genre. They expect the music to stay in the same place after the change from string to list type. The auto-calculated field Album Artist (auto) requires likewise. To accommodate this, in some cases, expansion of the fields needs to provide only the first item in the list, as the primary item.
The pass at making the string to list changes hit most of the affected code areas, roughly. Now real-usage is showing where the rough spots need to be smoothed.
Lists are funny things in MC - they are treated by the UI essentially as just strings, with some separator characters. So functions like ListCount() can just run through the string and count, split, return an item. And you can manipulate/create them with other functions. While this is a special, simple implementation, it creates some curious side affects. What would it mean, otherwise, to say a given folder path component should be based on some "list"? Does the list get "flattened"? How are separators included/chosen during flattening?, What is the order of list items? What happens when the interpolated list's length is too long? These are just some of the issues that have to be managed, and they become complex when they're spread throughout a large code base.
So, if you want the full list (or raw data from a field), use the [fieldname,0] notation. Otherwise, the default [fieldname,1] (formatted data) expansion is used.
Now, if you post your full expression, we might be able to show you how to simplify it. Given its description, I have some ideas.