Thanks Dan, your branch is a great improvement. I think I can also see what's going on in Tina's examples too. The Source Path separator is different between the XUL and web clients: The XUL Client uses both '->' and '::' depending on how many layers down the tree you go, while the Web Client instead only uses '->' regardless of the number of links traversed. So when you clone a simple XUL report that results in this SQL:

SELECT	"67bf5c5e1a824cdc5d44508d00cf2ff7"."barcode" AS "Barcode",
    COUNT(DISTINCT "e443e095dd88083d1a9da7e3630b7185"."id") AS "Use ID",
    "076bf6f3642cbc96b197e17f5bc8943e"."circ_count" AS "Total Circulation Count"
FROM	action.in_house_use AS "e443e095dd88083d1a9da7e3630b7185"
    RIGHT OUTER JOIN asset.copy AS "67bf5c5e1a824cdc5d44508d00cf2ff7" ON ("e443e095dd88083d1a9da7e3630b7185"."item" = "67bf5c5e1a824cdc5d44508d00cf2ff7"."id")
    FULL OUTER JOIN extend_reporter.full_circ_count AS "076bf6f3642cbc96b197e17f5bc8943e" ON ("67bf5c5e1a824cdc5d44508d00cf2ff7"."id" = "076bf6f3642cbc96b197e17f5bc8943e"."id")
WHERE	"67bf5c5e1a824cdc5d44508d00cf2ff7"."circ_lib" IN ($_15939$335$_15939$)
GROUP BY 1, 3, 4
ORDER BY "67bf5c5e1a824cdc5d44508d00cf2ff7"."barcode" ASC, COUNT(DISTINCT "e443e095dd88083d1a9da7e3630b7185"."id") ASC, "076bf6f3642cbc96b197e17f5bc8943e"."circ_count" ASC

in the web client and try to add the Active Date field (following the same right join path, as expected) you'll still end up with something like this:

SELECT   "67bf5c5e1a824cdc5d44508d00cf2ff7"."barcode" AS "Barcode",
    COUNT(DISTINCT "e443e095dd88083d1a9da7e3630b7185"."id") AS "Use ID",
    "076bf6f3642cbc96b197e17f5bc8943e"."circ_count" AS "Total Circulation Count",
    "92632112b9e5a769d2fa4b1c967657f5"."active_date" AS "Active Date/Time"
FROM  action.in_house_use AS "e443e095dd88083d1a9da7e3630b7185"
    RIGHT OUTER JOIN asset.copy AS "67bf5c5e1a824cdc5d44508d00cf2ff7" ON ("e443e095dd88083d1a9da7e3630b7185"."item" = "67bf5c5e1a824cdc5d44508d00cf2ff7"."id")
    FULL OUTER JOIN extend_reporter.full_circ_count AS "076bf6f3642cbc96b197e17f5bc8943e" ON ("67bf5c5e1a824cdc5d44508d00cf2ff7"."id" = "076bf6f3642cbc96b197e17f5bc8943e"."id")
WHERE "67bf5c5e1a824cdc5d44508d00cf2ff7"."circ_lib" IN ($_2397$335$_2397$)
GROUP BY 1, 3, 4
ORDER BY "67bf5c5e1a824cdc5d44508d00cf2ff7"."barcode" ASC, COUNT(DISTINCT "e443e095dd88083d1a9da7e3630b7185"."id") ASC, "076bf6f3642cbc96b197e17f5bc8943e"."circ_count" ASC, "92632112b9e5a769d2fa4b1c967657f5"."active_date" ASC

Where the hash "92632112b9e5a769d2fa4b1c967657f5" is assumed to be the same path as hash "67bf5c5e1a824cdc5d44508d00cf2ff7" (because it is, except for the difference in separators) and so isn't defined anywhere, leading to a FROM clause complaint.

This leads to a situation where it's possible to clone a XUL report and manipulate it in the web client, but actually adding new fields to the reports is highly unlikely to ever succeed. 

I'm open to suggestions on how to proceed here, should there be a key dropped in the JSON that triggers the old "source -> path :: path" style of source specifier for reports of that era, or should all of the hashes be re-generated every time a report is saved (I haven't checked the format to see if that even makes sense), or should the web client reporter just be changed to match the old format (do not want), or something else?