Thank you both for the feedback itís good to see what perhaps should and shouldnít go together. 

I think the prediction module could be better described as qsar (with the renaming of the current qsar module) or else descriptors, since the module doesn't actually have code that makes predictions. In fact, I think it would even be OK if the descriptors were placed in the tools module

Yep that was the one i liked the least. With the qsars in tools thatís quite a large collection of disparate functionality. Actually as the descriptors could go in tools - maybe it makes more sense to have a descriptors modules that includes non-qsar descriptors (see below).

 * tool - yes. Does 'cip' really not go in base? I think 'isomorphism'
should be, although I appreciate that it might be superseded by SMSD?
Talking of which, I agree with Rajarshi that SMSD belongs in tools.
There are several packages and classes in there that could usefully be
moved to other places.

Out of interest why would you put CIP in base? I would say itís a stereo-descriptor, thatís only useful for labelling absolute centres (not that useful). Also yes isomorphism should probably go in base and I've moved that.

* display - can't 'control' be in display? I know controlling is not
displaying, but..

So yeah it is mainly used by JChemPaint and Bioclipse when displaying structures but Iím not sure it fits in with the renderers. Would need to think more about that - CDK-JChemPaint adds a lot of classes to the module that might make it clearer where it should live.

With regards to the 'qm' module, that looks like a
partially-implemented effort. The renderer seems like something for
rendering orbitals or something.
The qm.math stuff could be packaged with 'group' ? Perhaps a module
(not a super-module) called 'mathí.

Thatís a possibility - we can do merges once all is in place. I think it might be better just to deprecate the code though - leaving it still in place for people to use but indicating this isnít (and most likely wonít be) completed.

Oh, and for that matter -
shouldn't signatures be with inchi and smiles?

Are you able read signatures back as an AtomContainer? I would have thought these are more similar to hose codes that describe  (i.e. descriptors) the environment of each atom?

Hereís an updated hierarchy with a 'descriptors' module.  Not sure about ionpot and charges - ionpot is only used by qsarionpot and charges by qsarmolecular, ionpot and forcefield. Let me know how this feels:

base
annotation
atomtype
core
data
silent
datadebug
isomorphism
dict
interfaces
reaction
standard
valencycheck
tool - that manipulate intrinsic properties and asking questions about structures
builder3d
builder3dtools
forcefield
formula
fragment
group
hash - aux property but used for testing identity rather than describing something
pcore
sdg
smarts
smsd
structgen
tautomer

descriptors - that compute auxiliary attributes to be used for building models and screening 
fingerprint
ionpot - hmm.. there are already ion pot and charge qsar descriptors, these are kind of intrinsic but kind of only used in the qsars..?
charges 
  cip
signature
qsar
qsaratomic
qsarbond
qsarcml
qsarionpot
qsarmolecular
qsarprotein

storage 
io
ioformats
iordf
libiocml
libiomd
pdb
pdbcml
inchi
smiles

display
render
renderawt
renderbasic
renderextra

deprecated - old code that is not used in the library but is required for backwards compatibility, only included in downstream projects when needed

miscellaneous 
control
extra  
diff   
log4j  
qm