suggested handling for a closed loop

[MisterHW]

change signature to
module skin(profiles, no_endcaps=false)

change last line to
polyhedron(convexity=4, points=profiles, faces = no_endcaps ? triangles : concat(start_cap, triangles, end_cap));

duplicate vertices are acceptable (https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Primitive_Solids#Point_repetitions_in_a_polyhedron_point_list) so when the first and last profiles are identical this produces e.g. a closed toroid.

[dpellegr]

This may fail pretty brutally if due to rounding errors in the computation the final points differ a bit (or if the user makes a mistake). I have produced a pull request which recycles the first points so that there is no need to duplicate points and the closure is always guaranteed. See #12

[MisterHW]

Maybe a good solution for the users. no_endcaps as suggested above still does exactly what it says and is only guaranteed to produce manifold geometry if the last profile is a copy of the first one and should be unique functionality. Depending on the resolution error handling of CGAL, the usefulness is limited by transformations incurring further numerical errors.

In https://github.com/MisterHW/IoP-satellite/blob/master/OpenSCAD%20bottle%20threads/azimuthal_profile.scad that exact mistake is made to rely on roundoff-error-free behavior of trigonometric functions.

Ultimately however I feel that calling the feature 'loop' invites +/-1-type misunderstandings, as it's unclear whether loop describes a property of the profiles passed or whether it's a parameter controlling skin(). Nitpicking aside, close_loop or bridge_ends might leave less room for confusion?

[dpellegr]

Yes, I didn't pick the name as the flag was already there albeit unimplemented.
However IMHO the profile is always (assumed) a closed loop (otherwise it is impossible to define the inward and the outward faces) so there is no ambiguity.

Let's now see if one of the maintainers take action...