Yes, typesetting applications need to know about included objects such as images (and fonts). But from there you conclude that there's a benefit in generating PDF directly. I don't see how this follows.
The key to understanding the “benefit in generating PDF directly” lies in the adverb “directly”, not the noun “PDF”. We appreciate having a single program that has all the necessary knowledge about the end result.
LuaTeX does (a) and (b) at the same time.
Not at the same time, within the same program. Those actions do not need to be carried out at the same moment, but it's useful that the parts of the program that are responsible for them are able to communicate with each other to exchange knowledge about the material being typeset, without duplicating code, as Martin said.
I see no reason why a 'special' that says 'do (b)' should not be written to the xdv or whatever output file.
Maybe it's time that we turn the question the other way round and ask you for reasons to *do* so. What, could you please tell us, is so great about *not* generating the end result directly that we should force ourselves to produce an intermediate file first, and even go on about inventing a new format, because the current extensions to DVI lack some necessary features?
[Discussion of performance snipped]
It's a pity you don't want to discuss this, because it's the only technical advantage to producing xdv that I have seen mentioned so far.
Well, it's not MY code, but I'm sure you're welcome to use it: http://scripts.sil.org/svn-public/xetex/TRUNK/ http://scripts.sil.org/svn-public/xdvipdfmx/TRUNK/
That's XeTeX's code. The LuaTeX developers are well aware of XeTeX's existence and features, but what you may be missing here is that LuaTeX is not XeTeX and is not destined to be, nor the other way round, for that matter. They simply serve different purposes. Your insistence in having LuaTeX produce xdv seems to proceed from the assumption that XeTeX's novelty resides in xdv, which is in my opinion the wrong angle on this issue: XeTeX's most valuable asset is XeTeX, the program, itself, not xdv production. And xdvipdfmx, the postprocessor, doesn't have such prominent features that couldn't be implemented within LuaTeX, as Barry pointed out. As for LuaTeX's specific features, they would not be very well expressed by xdv, and can be fully accounted for by generating PDF. Arthur