Hey @BobH!
This is correct behavior for how the list view is implemented.
For this type of implementation, I would recommend a structure of two tables: Projects and Tasks.
From there, you would leverage a linked record field to define the dependencies between different tasks.
I recommend this for two reasons.
Firstly, this would resolve the potential confusion that might come from having two tables and would allow you to keep a consolidated and more semantically friendly list view. This is particularly true since list views have native support for displaying parent/child dependencies. It's worth noting that child-to-parent defined relationships are not displayed. The dependency must be a parent-to-child relationship to be properly displayed.
Secondly, this is in line with a cleaner schema and overall database design best practices.
When thinking about tables in a database, each table should hold records for a specific type of thing.
If two tables both store records for the same type of thing (in this case, tasks), then you set yourself up with a considerable amount of technical debt before you even start thinking about your fields, automations, and views. It's easy to say that it's no big deal and write it off as something that can't do much harm, but in my time working in Airtable and with the data structures of many teams and organizations, I can attest that taking the approach of separate tables for the same entity type has never turned out to be a good idea in the mid-long term.
If you are concerned about your users and their workflow experience, then I would recommend that you don't share the base with them at all. Instead, craft an Interface that will fit their needs and eliminate the need for them to manage views, worry about which table is the correct one, etc.
