Situation description:

We have a multivalue fieldType that referts to userIds.
We want to express (using the ACL) that users only have read (write, delete, publish) access to documents if they belong to the list of userIds.

(Perhaps this document should be merged with Bruno's ACL musings see the 'missing features' section)

Analysis

Approach 1: (doesn't work)

Write an acl object using this condition:

if $UserIdField=UserId()
  then
    everybody = grant read, ...

Why doesn't this work (technical reason): The UserId() function checks the user on the current evaluationContext's repository.  For ACL evaluations, this user is $system, hence UserId() will return 1 instead of the 'current user id'.

Why doesn't this work (conceptually) An ACL object should consist of an expression and a list of entries.  The expression determines the documents that the object applies to while the entries expresses which users receive which grants/deny's.  With the acl object presented above, the distinction becomes blurred, potentially making the ACL more complex and difficult to understand.

Approach 2: (suggests implementation change)

Focussing on the ACL entries: Recently we added 'owner' as possible principal for ACL entries.  Perhaps allowing some sort of expression in the ACL entries would be nice, e.g. referring to $UserFieldType (note: that's not all, think about projects using a 'USER' namespace for documents describing users, although that's very specific).

Another point of view (or taking a step back):

What are we doing here?  We have ACL rules that are very fine-grained: per document, a list of users having access is specified.  It way too inconvenient to change the ACL every time the value(s) of $UserIdField change, hence an expression is used to make the ACL 'dynamic' (and more important: to place the access rules under control of the people who can modify $UserIdField - a feature we have supported since some time, but only to control the ACL object expressions, no to control the ACL entry principals.