Flexibility is what made Jira into the monster it is! Jira can model any workflow so that any company can purchase it. If you are running into problems because transitioning issue types loses fields, why not make all types have the same fields? or have only one type? In a lot of teams, the answer is - “because that’s what the person who configured Jira made it do”.
And fulfilling laundry lists of feature requests will turn your system into a Jira - can do anything if you have someone whose job it is to configure it. Which is fine if you want to be another Jira, but that might be a tougher challenge than being an opinionated alternative.
I want it to be flexible to the end user. Jira is about flexibility in how you restrict the end user.
I think this means that it won't require much flexibility as the users can do a lot of what they want, leaving teams to organize themselves with the workflows that work for them.
The things that I would really like to see are:
1. First class support for dependencies. I want to easily see what a particular issue blocks and what blocks it. I want easy buttons to add a blocking issue or a blocked-by issue. (Also make it super easy to create new blockers which is great for breaking down tasks). I would also love a tool that can tell me what I can work on now, where I can make progress. Basically I want to be able to make a search for my open issues which don't have any open blockers.
2. Performance is very important. It can be fake (do everything in the background and confirm when it is done syncing to the server) but I want to dump things down so I remember them and I can sort them out later.
3. Keep everything flexible. For example I see issue types as an anti-pattern as they restrict what you can do. I often transition issues between types in Jira and end up losing half of the info because it isn't allowed in that schema. I want to track an issue of time so and requirements/plans/priority change over time so I need to be able to change everything about the ticket without losing valuable history.
4. Some sort of simple scriptability. I often have a situation where I run ls, grep or some other quick tool to generate a list then want to file issues for all of the results so I can then work my way through them. So I want an easy way to dump these into the bug tracker (probably as blockers of some other issue).
5. An email interface. I work out of my inbox and the ability to read and respond to issues from my inbox is sooooo convenient. Bonus points if I can do actions such as open/close/add blockers with an email response as well.
6. I also think the concept of "projects" is largely a mistake. Issues switch between project or cut across all of the time. I think tags are generally a more flexible option that satisfies most of the use cases. (A really nice approach that I saw was the ability for anyone to create "lists" which were used a lot as tags. So you can have a "project:foobar" list and a "backlog" list and manage those. This is also more flexible because a ticket can be in as many lists as you want.
7. An amazing feature that I have only seen from launchpad is integration with other bug tracker. My work often depends on other projects which run their own issue trackers. It would be amazing if I could depend on external issues just like internal ones.