the link between the parent document and the response is the parent documents unique id.

Maybe it's just me... but I see very little benefit to using actual response documents in the XPages world.  

Sure In SSJS you can use the doc.responses property which is nice...  but if both related documents were main documents with a shared key it's not that difficult/expensive to get them other ways.

Also remember there's less needs to duplicate data between parent doc / child doc as you can now do more live lookups inside views and repeat controls and stuff.  

Just a couple comments I guess.

Dave

There are several problems that I have run into. First if there is a save/rep conflict when it is resolved the the UNID may be changed. Second you don't have access to the real UNID until after the new document is saved. Which in your case it would appear to be to late.

Plus in XPages the repeat control can do everything that you want to do with a response document. Plus I have created three/four level deep 'response' with each level having it's own @Unique value, but I also keep all the interveening values so that the fourth level down knows it's top level parent. There might be a slight improvement by finding a document by UNID versus a getDocumentByKey in a view but I think it would be pretty near impossible to measure.