Issue 59132

This kind of feature has a very wide scope so I'll try to sum it up.

The shortest way to put it from the user side would be "make CustomShapes more
custom" but it wouldn't reflect the implementation side of the problem.

Use case :
Building compound ( paths + text boxes ) objects whose properties ( geometry AND
style) are bound through static constraint relations. Some of the properties can
be modified by custom controlers ( handles or the like).
The constraint set must be preserved when copying-pasting-importing from/to
gallery. 

In the current state this is partially possible :

- by macro through the API : one can attach customdata to a shape so that a
macro set can refactor the shape using user provided parameters. All aspects of
the shapes are modifiable.
- by cutom shapes objects : the object is built by a rendering engine following
static rules embbeded in the object xml description. 

What is lacking :
- macros sets are not bound to the object. If the shape is exported to a
installation lacking the macros, the logic is lost. Moreover, the adjunction of
CustomMetaData is more a hack than anything else. All in all, it's overkill as
in most real use cases , graphical constraints can be expressed as a set of
rather simple static rules.
-CustomShapes are only concerned by geometry of one set of subpaths. It is not
possible to attach multiple styles to different subpath ( which is coherent with
 the "one style-one path" mapping). It's not possible either to attach various 
text objects whose positions would be bound by equation. ( one object - one text
 mapping).
Very simple example : 
One can build a triangle whose points positions are fixed by handles, but it's
not possible to assign a text box to each point following the handle position
when it's moved.

As to possible solutions...

- extending CustomShapes to support multi-styles and al : seems a bad idea as it
 would break the object hierarchy.
- extend the concept of Shape Group to support equations and handles : the scope
of the constraint set would be limited to the group. Each object inside the
group only exports   a fixed set of properties ( position, style, values of
parameters ). The group itself can export his own set of parameters, allowing
nesting of group while preserving encapsulation to avoid the renderer going mad.
Handles ( or other kind of controlers) would be activated only on the current
level of editing in the Group hierarchy.
- support full SVG compliance. ( and thus embbeded ECMAscript) :   more of a
holy grail than anything else....

As I have no idea of the current plans for future development of OOo in the
graphics area , these proposals may be completely out of scope but then, it
costs nothing to ask...