Your description of the process isn't quite right.
The kernel keeps track of which paths are mount points. Exactly how it does that varies between kernel, but typically the information is stored in terms of paths. For example the kernel remembers “
/ is this filesystem,
/media/cdrom is this filesystem,
/proc is this filesystem”, etc. Typically, rather than a table mapping path strings to data structures representing mounted filesystems, the kernel stores tables per directory. The data associated with a directory entry is classically called a dentry. There's a dentry for the root, and in each directory there's a dentry for each file in that directory that the kernel remembers. The dentry contains a pointer to an inode structure, and the inode contains a pointer to the filesystem data structure for the filesystem that the file is on. At a mount point, the associated filesystem is different from the parent dentry's associated filesystem, and there's additional metadata to keep track of the mount point. So in a typical unix kernel architecture, the dentry for
/ contains a pointer to information about the root filesystem, in addition to a pointer to the inode containing the root directory; the dentry for
/proc (assuming that it's a mount point) contains a pointer to information about the proc filesystem, etc. If
/media/cdrom is a mount point but not
/media, the kernel remembers in the dentry for
/media that it isn't allowed to forget about it: remembering about
/media isn't just a matter of caching for performance, it's necessary to remember the existence of the mount point
For Linux, you can find documentation in the kernel documentation, on this site and elsewhere on the web. Bruce Fields has a good presentation of the topic.
When the kernel is told to access a file, it processes the file name one slash-separated component at a time and looks up the component each time. If it finds a symbolic link, it follows it. If it finds a mount point, no special processing is actually necessary: it's just that the inodes are attached to a different directory.
The process does not use inode numbers, it follows pointers. Inode numbers are a way to give a unique identity to each file on a given filesystem outside of the kernel: on disk, and for applications. There are filesystems that don't have unique inode numbers; filesystem drivers normally try to make up one but that doesn't always work out, especially with network filesystems (e.g. if the server exports a directory tree which contains a mount point, there may be overlap between the set of inodes above and below that mount point). Rows that map name to inode number are the way a typical on-disk filesystem works if it supports hard links; filesystems that don't support hard links don't really need the concept of inode number.
Note that information about mount points is stored only in memory. When you mount a filesystem, this does not modify the directory on top of which the filesystem is mounted. That directory is merely hidden by the root of the mounted filesystem.
struct stathas fields st_dev (ID of device containing file) and st_ino (inode number)