I have an account tree like: health insurance |-- person 1 |-- 2022 |-- 2023 |-- person 2 |-- 2022 |-- 2023 I use this yearly sub-accounts because reports using tags are completely broken at the moment and don't work at all for me (see my other bug reports for them). Unfortunately, if there are several different account with the same name (here: 2022, 2023), their transactions get aggregated into one account (named 2022 or 2023 resp.). So I'm forced to rename them to something like "2022 (person1 )", "2022 (person 2)" and so on. I'd expect different accounts to not get aggregated into one, even if they share the same name. Technically spoken, I don't expect a "group by account name" but a "group by account id".
Please specify exactly where you see this behavior. I am only partly able to replicate it. If I run a Transaction by Accounts Report, with the Rows/Columns tab set to organize by accounts, I do see 2022 listed only once, but it clearly groups the lines from one account all before the lines from the second account. The totals are only for the group, and not per actual account, so there is a problem, but it does look like you should be able to distinguish the two accounts. I'll start digging in to see if I can find why this is happening.
The same problem does not happen with Categories because in reports (at least those I have checked) categories are listed with their full hierarchy, not just the name of the lowest level category. I wonder if this might be a way to fix the merging by account.
Using the full hierarchy sounds like a very valid fix, since it would solve the issue. The point is, it doesn't make sense to aggregate accounts with the same name, if they are not the same, and I'm indeed interested in the sum for each account separately.
OK, I just checked and it's correct that the transactions of accounts sharing the same name are reported like "first account", "second account", so a human can split them by analyzing the transaction dates. But I think that's not the intention of reports grouped by account. So as I stated before, it would make sense to use kind of the full hierarchy (but without getting names extremely long, I don't know how that's solved for categories).
adjusting name of bug to better tell the problem