The Adobe DNG Converter now copies the contents of a MakerNote tag
into a DNGPrivateData tag (together with byte order and original
offset information) for several types of RAW files, most notably
those (such as files from Canon, Nikon & Pentax, etc.) where the
MakerNote tag is really a TIFF IFD, albeit with private tag types.

In that case wouldn't it be sensible to relocate the address data
in the IFD (for tags with more than four bytes of data, obviously)
to reflect the new location in the file, rather than just blindly
copying the original offset?

I know the DNG specifications call for addresses within MakerNote
and DNGPrivateData to be offsets relative to the start of the tag,
but that's an unrealistic expectation: TIFF IFDs expect absolute
addresses, not relative addresses. Presumably the reason that the
camera manufacturers chose a TIFF/EP layout in the first place was
so that existing TIFF libraries could be used to read and write the
file; forcing a MakerNote tag to be incompatible with existing IFD
parsers would seem to remove a significant part of this incentive.

I'd suggest another subformat of the DNGPrivateData tag (perhaps
'MakR' rather than 'MakN'?) that relocates the tag address fields.

Is there a document that describes the format of DNGPrivateData when converted from Makernote? (Eg. the way the extra information you describe is held).

I know Thomas Knoll said (in 2005, I think) that he would produce such a document, but I haven't seen it.

I haven't seen an official document from Adobe, but it's not that
hard to decode. In the DNGPrivateData MakerNote copy contents are:

1) Six bytes containing the zero-terminated string "Adobe"
(the DNG spec calls for the DNGPrivateData tag to start
with an ASCII string identifying the creator/format).

2) An ASCII string ("MakN" for a Makernote), presumably
indicating what sort of data is being stored here.
Note that this is not zero-terminated.

3) A four-byte count (number of data bytes following);
for a simple MakerNote copy this the length of the
original MakerNote data, plus six additional bytes
to store the next two data items.

4) The byte-order indicator from the original file
(the usual 'MM'/4D4D or 'II'/4949)

5) The original file offset for the MakerNote tag data
(stored according to the byte order given above).

6) The contents of the MakerNote tag. This appears to
be a simple byte-for-byte copy, with no modification.

I presume that if there is additional content to be stored
the process would start again with field (2) above, but I
have only looked at a few very simple examples.