I've been quite heartened that in this case it's not just me being in a marginal group. There certainly are a couple of layers to the discussion. I'm putting everything into one mail, a reply to the longer term, bigger picture, first. Then the immediate work-round after. Michael Prasuhn wrote in reference to the ORM article (http://groups.drupal.org/node/8001)

I think that's probably the solution to more Drupal problems than we realize. Once Author and all node fields are stored as multiple value CCK fields, multiple authors becomes trivial.

and Karen Stevenson wrote:

Actually, we really do need a core solution for this because of the fact that users are tied to nodes in so many ways other than what they display to the end user. ---%<--- I do think this may be an example of what CCK in core might do in D7 -- the node author becomes a multiple value userreference field instead of a single value field.

and possibly alternatively Earnie Boyd wrote:

I would suggest a more drastic change to core functionality and add a node_uid table with column of nid, vid and uid.

I think it's pretty much common here to go for an object/reference/node_uid that is the 'node author'. I'm not sure how this then fits with revisions - in a technical sense of the references or objects (but also see my note below). FWIW I'll mention here that one of the things that occurred to me while working idea (further below) was the problem of clashes between 'registered username' and identified 'registered node owner' username. Generally if there is some way to move towards an abstracted object owning the node that's brilliant! I suppose I can help somehow? Karen Stevenson also wrote:

Also, for whatever it's worth, whether you need this at all depends on your environment. --%<-- But when you start talking about books or when you're publishing material in the business or academic world, 'authorship' and 'ownership' of nodes needs to be more flexible.

This is the revisions thing. For most of the groups I work with (activist, NGO...) there is also an (admittedly small, but inverse to above) element of deniability that can be worked in here, so for me the revisions would also want to be 'owned' by the 'node author'. Tracking individual users is nice, but for these purposes it helps when it's optional. On a more immediate solutions Scott Reynolds wrote:

My approach did not involve just the node_access table, it used the og table (to determine if the user is an admin of the group). Just get rid of the og stuff and put in your node_uid table

So revised using node_uid table like as follows

hook__node_access_records() ...

I had also thought about this relating to OG and being able to have actual group posts. The workaround (suggested in the original e-mail) I wanted to avoid using hook_node_access... Not touching the node_acccess table is interesting, but I was looking not to get involved in moderating access between modules at all. Given the interest I'm still wondering if there is anything about my solution, or I should say workaround (above are solutions), is good. I'm guessing it's not going to run-aground so I'll give it a go! Cheers, ekes Original suggested answer^H^H^H^H^H^H^H workaround:

Write module that - (i) Creates a (blocked) user to register 'nicks' (ii) Links 'nicks' with user(s) 1->1 or 1->many (iii) uses nodeapi to add 'nick' to node form (iv) adds edit/delete to nodes that relate to user 'nick's (just skipping and adding different access control to present node functions).