If you make developments in that direction in the future, it would be great being able to associate categories across languages if possible, and to have the possibility to list all the tickets , whatever their language, into the page visited by the user. (not to translate the content of the tickets, only to list them).
There are two mutually exclusive ideas in there, neither of which would work for your.
Idea 1: Language associations. This is how Joomla does it for articles, menu items etc. We are not going to implement this. This can already be done with a hidden menu and menu item associations. Since this is a very standard method for building Joomla sites we don't even need to document it.
Idea 2: Display items from multiple categories on a single category's page. This is not going to happen EVER. It is a horrible idea on UX, performance, security and architectural level.
The performance is abysmal. Searching for a single category is an optimal operation for MySQL. It uses an index in a way that makes it super fast. Start adding categories and things gets wonky. In some queries it will not even use the index because it determines it's faster to just go through the entire dataset.
From a UX perspective this idea is a mess. No pagination, no searching, no filtering by status, no SEF URLs, no New Ticket button and the list goes on.
Each category has its own view level and permissions. Trying to merge them creates a major issue. What is the effective view level and permissions of the union? There is no universal way to determine that. Any implementation will lead to several cases where people see content they shouldn't or are able to file or administer tickets when they shouldn't. It's conceivable that because of the complexity of the code this would introduce a vulnerability which would allow an attacker to covertly exfiltrate private information.
As for architecture, this adds a level of complexity that permeates the entire component. For marginal gains we are introducing a slew of conditionals and ungodly tricks which will make the code far harder to maintain and introduce bugs.
In so many words, no, I am not going to do it. I know better than to make this kind of colossal mistake.