harring wrote this, so it may be completely wrong (jason, fill something in here if it is please :)
shouldn't know about use flags, but what of slots?

re: use, hard deps and soft deps.  hard deps are deps that *cannot* be avoided via conditional trickery.  
Only type of conditional that has it's deps marked as hard are arch deps, x86? ( blah ) fex.
everything else is marked as 'soft'.  So process

1) resolver normally is operating on the full depset.  iterates over the depset, getting back matches, and (via it's own internal logic)
   deciding which returned pkg to merge per atom.  It *should* track the returned pkgs, althuogh the caching of that is another thing.
   at the very least, atom : pkg should be tracked.  Technically should track what pkg gave it that atom also, but that's user report 
   related.

2) slot/use cycle encountered.  x requires y which requires x-
   note this is for ebuilds, buildables that require rdepend be satisfied, *and* depend.  binpkgs aren't affected by this.
   a) is either of 'em merged, and would the merged version satisfy the requirements of the other?  eg, is x merged, but y isn't, and 
      x will be upgraded? (if merged x matches y's atom, then merge y, then upgrade x).
   b) is x in y's hard deps?  no? poke (define method hook for this) y to get what conditional(s) control x being required, then 
		re-request from the repo that pkg with the new restrictions (disabling x requirement), merge that, then merge x, _then_ remerge
		the original y (which depended on x).  Cycle sidestepped.
   c) is y in x's hard deps?  See above if not (same process)
   d) If made it this far, it's a *hard* cycle.  iow, you're boned if this is your only repository.  Time to query other repositories,
		see if you can track down a satisfying set of binpkgs to work from (or that satisfy conundrum above, somehow).
	e) no binpkgs?  You've just ran into x-ver1 deps on =y-ver2 and y-ver2 deps on =x-ver1 , with neither merged.
		No way out.

different resolvers at runtime;
1) how to recreate -u if the user can define whatever resolver they want via config?  Request obj or something?
2) where do sets mix in, and how does the resolver get the set of atoms?
	a) where are user defined sets, errm, defined? /etc/portage/sets is a fine location, but it *must* be represented in the config in 
	   some way, and the parser (generator of sets) is via the class def.
	b) sets that are dependant on what's merged (glsas); how?
		1) glsa set is bound to a repository obj (specifically, vdb).  This works for upgrades, but doesn't work for binpkg rebuilds, 
		   moreso, requires a second glsa set defined to the repo.  icky.
		2) glsa set is AndRestriction(built/binpkg, OrRestrictionSet), with the orrestriction being massive, the full glsa ranges needed to
		   dodge out of any security issues.
		3) both?

3) inter-resolver chats.  domain x (x-compile ppc) needs bdepend solved out of domain y, how does x request from y?
4) further, how is this buildplan designed/written (graph obviously), how does ui tell it to 'start' ?  or does ui execute the buildplan?
   (yes that sounds insane, but it should be simple enough, no evil voodoo).