Thanks for your consideration in discussing with me an importante topic. I think that you are one of the few persons that are fighting to put this facility in the reality plan. And I would like to still discuss these topics with you in the future.
I think that the goal of the WMF DTF is to define a standard that could be possible the componentization and interoperability of a workflow management system. We also know that only the definition of the interfaces (syntactic interoperability) is not enough to the componentization. It is also needed to define the semantic of this interfaces at formal level (and sometimes is also needed to specify non-functional requirements as part of the contract but this is a future problem). The last is very dificult to be achieved but is needed to create an open standard.
But as a scientist I will to disagree with some points about your arguments in order to justify the stripping of the inheritance relationship between a WfActivity and a WfRequester. I think that you like to be a kind of Object-Oriented Jake Stripper

I found that the resolution text of issue 2041 had a problem.

In the text the following operation is added to WfExecutionObject interface.

boolean is_member_of_history(in WfExecutionObject member)
raises(WfBase::BaseException);

I think the argument "WfExecutionObject member" is strange because the
operation is named as "member of history".

Is it WfEventAudit ?

If it is WfEventAudit do we have to raise a RTF issue?

The UML diagram from the 1.2 version shows the aggregation
between WfProcess and WfActivity and the aggregation between
WfActivity and WfAssignment as aggregations with unidirectional
navigability (open diamond). These two aggregations should be
of typ[e composite aggregation with bidirectional navigability
(filled-in diamond).

Summary: Section 2.6.3 and the object model in Figure 2-1 state that there must be a
WfRequester associated with each WfProcess. Registering a Requester is useful
in scenarios where some entity is actually waiting for the process to complete.
There are several scenarios where this is not the case; for example when a
process is started in a chained sub-process scenario or when a process is
primarily started because of its "side-effects" (achieved by its Activities) ,
not to retrieve its results. In this case the status queries provided by
WfProcess are sufficient to allow an administrator to observe the WfProcess.
Making Requester mandatory implies that someone must keep a persistent object
around for a potentially long time even when there is no real use for it.

I propose to make the association between WfRequester and WfProcess optional
(i.e., cardinality of "requester" would be 0..1 instead of 1).

The spec says in section 2.4.5 that the state of WfExecutionObject can be
set to closed.

state.
Correct Figure 2-2 so that we can clearly understand the transition to
closed.completed state is permitted only from open.running state.

Summary: With respect to WfExecutionObject and WfEventAudit I am wondering if there
has been any consideration for loops in a workflow.

E.g. Would it be possible for the same WfExecutionObject to be executed
twice because there was a rework loop in the process definition ?

How would this impact the state diagram for WfExecutionObject ? There does
not appear to be any way to move "back" from closed to open.
How would this be handled by the WfEventAudit records ?

The UML diagram from the 1.2 version shows the aggregation
between WfProcess and WfActivity and the aggregation between
WfActivity and WfAssignment as aggregations with unidirectional
navigability (open diamond). These two aggregations should be
of typ[e composite aggregation with bidirectional navigability
(filled-in diamond).