Problem:
The ProjectMember (and various other classes e.g.
Project or Library) contain

  public Lookup getLookup();

method. Unfortunately it's hard for the developer
browsing the docs to find any further information
of what is publicly available in the particular
lookup. As the lookup contents are defined by the
implementing modules there can't be any useful
content description in ProjectMember.
 If the implementing modules do not care enough
for the lookup content the following situation can
arise:
1) the module m1 makes a public class Foo
available in the lookup in version 1.1
2) the module m2 depending on m1 starts to rely on
m1 to provide the Foo class in the lookup
3) the module m1 no longer provides the class m1
in the lookup in version 1.2
4) module m2 functionality gets broken.

Although the module m2 could always check for the
case when it finds null in the lookup the module
cannot declare reliably when it works and when it
does not work. The developer must add extra
null-checking code that affects code readability
and requires the developer to think "what should I
really do if this particular class is not
available in this lookup?". 

Possible solution:
IMHO once ad1) happens the module would have to
decide whether the Foo class should be made
publicly available to the API clients. If it
should be available the module would be required
to declare a public method in a utility class:

public class m1ProjectMemberLookupUtilities {

  /**
   * The following method obtains Foo instance
   * from the lookup of the given projectMember that
   * satisfies those and those conditions.
   * @return valid Foo instance if the conditions
   *  above are satisfied or null otherwise.
   */
  public Foo getFoo(ProjectMember pm) {
    return (Foo)pm.getLookup().lookup(Foo.class);
  }

}

 If the utility method would not be available then
the Foo class could not be assumed to be publicly
available in the lookup by the module m1 and no
module should rely on its availability in the
particular lookup. On the other hand once the
utility method gets created the contract gets
created and the module must make sure that it
provides the Foo class in the particular lookup in
the next module versions (unless it deprecates and
removes the utility method).
 There could be similar approach taken in the SPI
of the particular module.

 IMHO this could increase usability of the modules
building on top of projects for their clients
wishing to extend them:
1) From the contents of the utility class the
clients would know all the classes that can be
found in the particular lookup.
2) The clients would know the conditions under
which the particular class will be available in
the lookup.
3) Modules could rely on availabity of the
particular class (under the specified conditions)
without extra null-checking code.

Any comments?