Shift-D node duplication no longer works

Followup: I've been doing some research, and it looks like the functionality probably disappeared when the GSoC node work for last year was merged into mainline here:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/8976#src/node-context.cpp
Specifically highlighted is the file where I believe to be the culprit was removed. Perhaps the developer should be contacted.
(Specifically, I'm looking at lines 588-593 in node-context.cpp, which is where I'm thinking the key is captured; I'd use that as the starting point in sorting the rest of this out...)

reproduced with Inkscape 0.47+devel r9294 on OS X 10.5.8

Still doesn't work with 0.48. Changing milestone to 0.48.1.

Fixed in r9685 in the stable branch. Also fixed in trunk in r9726.

@Krzysztof - in Inkscape 0.46 and 0.47 the duplicated node(s) are selected after the command is executed, not like currently (Inkscape 0.48+devel r9834) the originally selected ones. Or differently phrased: in current trunk nodes appear to be inserted in the reverse direction of the path (towards the start) whereas in previous versions nodes had been added following the path direction (towards the end) - determined by the content of the selection after the duplication.

One main usage was to continue an open (sub-)path from within the node tool by duplicating the end node and moving it away (e.g. with the cursor key).

Is there a reason for changing the behavior or would it be possible to make the command act identically to previous versions?

Correction: my previous comment wasn't precise: the difference appears to be limited to how start and end nodes are treated: in 0.47 duplicating either one adds the node as new start or end node and extends the path, whereas in current trunk, start and end node add the node in reverse path direction: extending the path at the start node and inserting a node before the end node of the path.

Another difference is how the handles are duplicated: in 0.47 the original and the duplicate have the same handles, in current trunk only one handle is duplicated and the segment between the original and the duplicate is a straight line (handles retracted).

Handle duplicaton behavior is on purpose - the old way introduces visual artifacts into the path. Endnode issue is fixed in trunk 9962.

Backported to 0.48.x in r9749