Hello, many thanks for reading and taking the time to look into this, and for your comments!
First let me start by the end and say I totally understand and respect the hesitation/reluctance when it comes to things like this! Especially considering how to migrate existing projects / instances to a new structure without corruption, data losses, etc. It would be a different story starting from scratch. Yet I thought it was still worth suggesting, given this approach tries to streamline / simplifies the concepts inside the app, making most things tasks/cards other than top-level projects, and so while it does involve changing a few things for tasks so they can be more like projects (e.g. making them shareable) and converting sub-project into cards, I thought it might be possible to find a reliable and clean way to do it.
Also in the long run it feels it would allow for a cleaner and easier evolution for the app by having less, yet more consistent concepts that clearly integrate through the different level in a project hierarchy (both for teh devs and users, since as noted in the forum thread linked in my post above, there already seems to be confusion brought by the current implementation of sub-projects).
Yes there is indeed a big crossover!
Wekan for example creates subtask in a separate board, which in Vikunja would be “another project” 
. In Wekan it is technically possible to set the “sub-task board” as the current board which then reproduces the current Vikunja behaviour, but this is not the default and is a pretty niche use-case.
There could be a setting at the project level that can be ticked on and off “create subtasks as a sub-project” so that users could opt-out of if they don’t like that behaviour. But this does not (have to) alter the concept of sub-projects being task (of parent project), it simply means that in some case, sub-task are created but the parent task does not become a project and in other cases it does.
Sub-projects are already collapsible which helps a lot with the keeping the UI manageable. One other thing could be to add a setting at the sub-project level to be able “hide/unhide” the project from the hierarchy if that was really an issue.
I mean sub-projects would show-up as tasks in the parent project and so would appear in the lists/gantt/table/kaban views of the parent project which allows to keep track and organise the progress of the parent project in relation to its sub-project (see screenshots below)…
…which unfortunately is not currently possible to do with filters.
I have sent you an invite to a moke up of what I mean on a vikunja instance where I manually demonstrate the concept (the invite will come from a Cloudron on the domain chourmo.net) - caveat is that some of the list view will be broken because of the issue with subtasks reported on Github.
Btw solving that GitHub issue about the subtasks not showing up in the list view would at least allow to manually create the suggested behaviour in this thread (i.e. manually creating sub projects=parents tasks and chuck the subtasks in it to create a fully organised hierarchy made of tasks and subtasks from the top level project). E.g:
