MultiLineStringZ not working when as first argument for ST_Intersection

[WaltDixie]

On POSTGIS 2.2, using geos, multilinestringZ aren't handled as expected when used as first argument in ST_Intersection.

Compare sect1bad to sect1best, sect2bad to sect2best in the following query:

SELECT li, ST_NumGeometries(geoma),ST_NumGeometries(geomb), 		
ST_AsText(ST_Intersection(ST_GeometryN(geoma,li),ST_Force3D(ST_Force2D(geomb)))) as sect1best,		
ST_AsText(ST_intersection(geoma,ST_Force3D(ST_Force2D(geomb)))) as sect1bad, 	 	
 ST_AsText(ST_Intersection(ST_Force3D(ST_Force2D(ST_GeometryN(geoma,li))),geomb)) as sect2best	,
 ST_AsText(ST_Intersection(ST_Force3D(ST_Force2D(geoma)),geomb)) as sect2bad		
  
FROM 		
( SELECT		
ST_GeomFromText('MULTILINESTRING Z ((0 0 10,0 1 11),(0 1 11, 0 10 20))') as geoma,		
ST_GeomFromText('MULTILINESTRING Z ((0 0 5,0 2 9),(0 2 9, 0 3 11))') as geomb		
) data		
CROSS JOIN LATERAL generate_series(1,ST_NumGeometries(geoma)) li(li)

GEOS 3D intersection should lead to the average Z-coordinate at each node of the intersection. This is correctly handled in the 'best' cases, where the first argument is split into its component LineStringZ segments. However, in the 'bad' cases, where the first argument is a MultiLineStringZ, the 'inner' node does not have the average Z-coordinate but rather retains its original value. Clearly this functionality can be avoided by splitting the first argument in its component geometries, but somehow this is not handled by default by the function.

[robe]

strk you think there is much we can do about this or just a limitation of GEOS in 3d, in which case we should just mark as won't fix.

[strk]

I don't really see why GEOS should not handle the multilinestringZ, so this sounds like a bug to me. Dunno if it's in PostGIS (not passing 3D to GEOS) or GEOS. Can you provide a GEOS testcase ?