I don't recommend implementing separate features that pass paramters to each other or have any cross talk between them.
I recommend implement a single feature with a module that loads on a cms page and is the entry point to the feature. Then from there you link to supporting pages (physical .aspx files) passing in the page id and module id and any other params you need. And implement a separate sitemap for your feature instead of trying to piggy back on the site map for cms pages. Your site map would have urls to the supporting page that shows the item detail. It sounds like what you have done is try to avoid creating supporting pages and just using more modules on cms pages and linking to cms pages instead of your own supporting pages, that isn't a good way to do it.
This is how all existing features in mojoPortal work. For example study the forums feature, it has several levels of supporting pages, and then the thread.aspx page is the thread detail and we build a site map with the urls for each thread. You could implement freindly urls but that is optional, the forums don't use them, but the blog does. In the case where a feature does use a friendly url the item must also know what the friendly url is so it can use it for its own links, ie the blog post has a database field where is keeps its own copy of the friendly url for the blog post, it doesn't know about the mp_FriendlyUrls table but there must be a row there so that the url rewriter knows to rewrite the friendly url to the real url, which in the case of the blog is /Blog/BlogView.aspx?pageid=x&mid=y&ItemID=x
So you should have a supporting page in your feature that expects all the url params to show a single item, whether you map to that with a friendly url or not is your own choice but is not required in order to have a google site map. If you do use friendly urls then your sitemap should use them like the blog site map does, but the forums for example does not and its sitemap uses the real url with the params though what we did there was combine a few params together since google recommends keeping it to just a few params. So for example now the forums passes only pageid and one extra param that has the thread id and pagenumber of the thread separated by a "~" the page number is just for pagination of longer threads. We derive the module id and forum id from the thread id and then verify those are valid and that the page actually contains the module to enforce security. In older versions we were passing module id, forum id and thread id which was not quite as google friendly.
Hope that helps,