Yes - good idea - but only if there is consensus that relationship attributes are the way to go.
I can see that using relationship attributes are easier because you can change them in a single edit from either end of the relationship. My concern is that (in database design theory) you only want to hold common details about something once in order to avoid the possibility of two items which should have the same information actually holding different information.
What I am not yet clear about is whether an MB work could be e.g. a Movement of a one main work, and an Act of another - in which case relationship attributes are definitely the way to go. Or is a Movement always a Movement, in which case we need to decide whether we are happy to accept the possibility that in MB it is shown as a Movement in one relationship and an Act in another?
(MB is NOT a transactional business database - so perhaps these sorts of inconsistencies are acceptable as they can always be ironed out by another edit later.)
Another point in favour of Relationship attributes is that I think that they might be more obvious than a work attribute and so more likely to be populated. (Work Type is left blank fairly often.)
When you create a the fact that it is a Movement is intrinsic to the work, and so selecting that as part of the work creation should not be a major issue. After all, we currently put it in the work title through a structured style definition, an you cannot change that when editing a parent or child work.
I have no axe to grind here - I genuinely want the best overall solution for MB.
I am not sure whether there are grey areas about whether something goes in a Relationship attribute or the Work Type. As an example, the Overture of an Opera is not an Act or Scene, so do you have a Relationship attribute "is Overture of"/"has an Overture) or do you put Overture in the Work Type field and ise "is part of"/"has a part"?
So - to try to move things forward...
Is there consensus that Relationship attributes are the way to go?
What is the definitive list of relationship attributes we now need?
Should these be sub-attributes of "is a part of" or separate sibling attributes?
Do we need to consider Work Type in concert, or can we leave it until we have defined the Relationship Attributes we need?