The first thing to know about query-writer is that it only does insert/update/delete queries. Select queries are a great way to shoot yourself in the foot. I don't know any better way to specify a select query than through SQL.
Second, is that the data model of query-writer allows you to specify metadata about objects. An object could be the rows of a table, or more complex objects like an acs_object which has data in multiple tables, but an object is essentially a collection of database attributes. Each object attribute can have a default value, or no default if it is required.
Using the object attributes, you can define __new, __set_attrs, __reset_attr and __delete functions. Any number of each could be defined. This is just a specification of which attributes, and which order. The type of function determines the form of the pl body. The current query-writer makes assumptions about the object's main table pk being a direct fk of acs_objects (something not true for a lot of objects). The new query-writer will correct that problem, because it will know where the fk points to.
Also I am adding points in the function body that would allow developers to add their own special code for the case you mention. If the body is really special, you can just specify a completely hand written body. I think the body will look like this in outline, for the __new function:
The current query-writer relies on a laborous process of adding object attributes by hand through a web interface. The new version will eliminate that and use a tcl api for specifying objects and defining functions.
I think I have said it before, but query-writer has three apis: one allows the developer to quickly port oracle queries to postgresql and works in .xql files, the second is a tcl api which is used on any tcl page that does updated/inserts/deletes. It can be used with ad_form, etc. The third is a url based api which allows the developer to use specially named form variables to create forms which can have any number of different objects and attributes per form, or multiple of a single object type. A single form can be used to insert/update/delete in a single click, and the backend query-processing doesn't need to be programmed. I wrote a 500+ file package with very few new-2.tcl, or other x-2.tcl files. The current version is available as an apm.
I notice the group type code creates similar pl, but fails quickly when the group type has more than a few attributes. When the new query-writer is finished, it should produce code that would also work for creating the group type code, but would write to a file and allow user code to be mixed in. Since you can have multiple __new functions, the limit on group type attributes would be removed by using this package.
I still want to find out how the views thing is supposed to work. If they still use __new functions, they would still have to be hand written in the case of more than 16 attributes, as a matter of fact, I doubt they would work the same. Maybe they create an acs_object, then the child of that, and so on up to the current object. That would work, but might be harder to program automatically.