Dependency ordering of stacks
During the cmake run the main source directory is scanned for stacks to build. Actually cmake does not care if it is a stack or a package; it cares that the directory has something there that indicates that it is buildable, and what its dependencies are... that, is stack.xml. Catkin topologically sorts this and reads the files in order.
Generation of find_package infrastructure
Each project calls catkin_project() which generates find_package files; this is for other packages to use. Each project does a find_package of each other; in this way, packages can build with their dependencies in the same buildspace, or already installed on the system. Different versions of these files are created for use in the buildspace, and in the installation. The stress-test for this scheme is message generation; different language generators must implement a specific cmake interface which is used by genmsg. See also Internals of the generated find_package() infrastructure.
Python path forwarding
A special thunk (via the standard python package pkgutil is generated and put in CMAKE_BINARY_DIR/gen/py/PACKAGENAME/__init__.py, which extends the PYTHONPATH to include CMAKE_SOURCE_DIR/path/to/PACKAGENAME/src. This way the buildspace PYTHONPATH need only contain CMAKE_BINARY_DIR/gen/py. Caveat: it will also need to contain CMAKE_BINARY_DIR/lib (for compiled python bindings). At installation time, this thunk-__init__.py disappears and the static python library source is installed alongside the generated message code in the same directory.
When cmake runs, it knows the locations of the CMAKE_BINARY_DIR and so forth, it generates an environment file (in CMAKE_BINARY_DIR). Projects may extend this environment via catkin_add_env_hooks().