Comment 3 for bug 1476028

Proposing to close this report as 'Invalid':
1) The reported behavior is to be expected based on the current implementation, and on the default preferences for clippaths and masks:
- Applying 'Object > Clip > Set' to a selection of multiple objects tells Inkscape to set a clip for each selected object using the geometry of the top-most element for the clip (for each clip to be set, a <clipPath> definition is created in the defs section, containing a copy of the top-most element of the selection for the geometry of the clipped region; and a 'clip-path' attribute is added to the clipped object, referencing its clipPath definition in the defs section).
- Applying 'Object > Clip > Release' to a selection of multiple clipped objects will apply the 'Release' command to each object individually, and the released clip-path will be retained as regular visible element for each of the formerly clipped object.
There is no command or session history associated with individual clip-paths or clipPath definitions in Inkscape (or SVG 1.1), or other data based on which Inkscape could second-guess whether or not the user wants to retain the released clip-path or not (e.g. in the reported case of repeatedly setting and releasing a clip for a selection of individual objects).
2) This is foremost a question about usage, not a bug: as mentioned by Maren, Inkscape does fully support alternative workflows to clip a large number of objects with a single clip by putting the objects into a group first (and to optionally handle such helper groups transparently if the preferences for clippaths and masks are set accordingly).
Note that using groups for such a task also brings the benefit of being able to easily add/remove objects from the clip, and to edit any of the objects within the clip without having to release the clip at all - please see the related section in the manual about working with groups (entering groups, selecting individual objects within a group, etc.):
http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Groups.html
3) There is no proposal in the report for an alternative clip command either, nor details how this could be implemented without breaking other workflows/use cases (e.g. optionally clip with a clone of a copy of the top-most object created in the defs section, and never retain a released clip-path if the clip uses a clone in the clipPath definition. Note that such a changed behavior on releasing a clip could break workflows for users who use clones for clipping (or masking) for other reasons than to be able to set and release clips on a selection repeatedly without re-adjusting the selection of objects or controlling whether the current selection still reflects the user's intent. It would also disable editing an applied clip-path or mask with the node tool since clones have no handles which could be adjusted with the node tool).