Let's say if we start a project with "Application Structure" as 'Framework and Implementation', why is that the New Application wizard generates 2 separate Work tables (Clones of pc_work) and 2 separate WorkHistory tables (Clones of pc_history_work)?

Consider the following scenarios (Let's say all Work Types of FW and Implementation layers are sharing same work table mapped to their respective Class Groups) :

1. Assuming  that Developers will creates cases while unit testing in FW application, we will never have to isolate these cases to that of the Implementation App cases physically in 2 different Work Tables. And also we never have to isolate history of cases created from FW and Impl layers into 2 separate tables.

(Since multiple classes can be mapped to one single table using 'Database Table' record, 'New Application' wizard should ideally be doing this)

2. Assuming that Developers will always access FW layer to define reusable records and not even a single case is created in that layer, clearly we do not need a table at all to which a FW Class Group or FW Work Classes need to be mapped to.

Majority times History tables are self sufficient and might not have new properties Optimized for reporting purposes. So there may not be maintenance overhead for history tables while it's still unnecessary to have 2 separate history tables. But for Work Tables, by chance, if someone considers this (New Applicaiton Wizard way) as a recommended approach, they will end-up maintaining 2 case tables, adding the over-head of promoting schema changes across QA, Staging and PROD environments (If the database user have restrictions on DDL operations the zip/jar file we import into QA/Staging/PROD won't promote schema changes automatically, and we end up supplying scripts to DBA's on 2 case tables instead of just 1).

Any answers, thoughts or comments are welcome.