The following table summarizes results of running a buffer against the dataset in source:trunk/tests/xmltester/tests/safe/buffer-1.01.xml

dist	GEOS 3.3.0 + patch	GEOS (b) OLD reduc stratg	GEOS (b) NEW reduc stratg	JTS (c)
0.35	Same output as 3.2.0	ok on 1st attempt, no reduction	ok on 1st attempt, no reduction	ok on 1st attempt, no reduction
0.75	Same output as 3.2.0	ok on 1st reduction (1e10)	ok on 1st reduction (1e5)	ok on 1st reduction (1e5)
1.01	Same output as 3.2.0	ok on 2nd reduction (1e9)	fail on 5th reduction (1e1)	ok on 1st reduction (1e5)
1.1 (a)	Same output as 3.2.0	ok on 2nd reduction (1e9)	ok on 1st reduction (1e5)	ok on 1st reduction (1e5)
1.5	Half incorrect (i)	ok on 2nd reduction (1e9)	fail on 6th reduction (1e0)	fail on 1st reduction (1e5)
2	Incorrect output(ii)	fail on 10th reduction (1e1)	fail on 6th reduction (1e0)	fail on 1st reduction (1e5)
5	Incorrect output(ii)	fail on 10th reduction (1e1)	fail on 6th reduction (1e0)	fail on 1st reduction (1e5)
10	Incorrect output(ii)	fail on 10th reduction (1e1)	fail on 7th reduction (1e-1)	ok on 1st reduction (1e5)

(a) aka TestBufferJagged.xml
(b) GEOS 3.3.2SVN r3523 / 3.4.0SVN r3524 on a 64bit system
(c) JTS rev.480

(i) Same as GEOS 3.2.0 in xmltester. Incorrect in GEOS 3.3.0 client -- same problem as (ii).
(ii) Output seems to have lost way too much precision.

Resources

diffnoding.gz contains the offsetcurve produced by both GEOS and JTS with reduction scale 1e5 and distance 1.01 against input.
The curve, passed to BufferBuilder::computeNodedEdges​, results in edges with a differently computed _depth_ between JTS and GEOS.