One of thee biggest difficulties of integrating an application into somebody else's framework is trying to keep everything tidy, organized and user-friendly. Passing data from page to page is made all the more difficult when trying to keep all those nice, SEO-friendly urls from getting dirty and illegible.
Because a CMS by its very nature operates within a content-based context, urls are by default going to contain page-only data. A good CMS will make sure these urls are SEO- and people-friendly, so that ugly ?id=UGLYUUID-THIS-JUST-SHOUDNTEXISTHERE doesn't rear its ugly head unless absolutely necessary. The problem then becomes, "do I as a developer wedge a bunch of code into the back end, start packing session (or worse, application) scopes with page data, or do I start tagging query strings onto the end of those pretty urls?" Sure, you could create a complicated chain of pages-with-components-inserted, but sooner or later a content manager will move or rename something and 'boom'.
Over the weekend, while working on what I hope will be a really revolutionary product for my clients and hopefully of some great use to the CF community in general, I realized that there was a little gem wedged in there that could prove really useful to Mura CMS developers. I'd played around with intercepting the standard Urls generated by Mura, manipulating them just before they got to the point when they asked the content renderer to match the path with it's related page data. In this way, we could say "this far, and no farther" on a particular page, and take everything else off the end as information for our plugin. It was all sort of manual and hard-coded, and the developer in me yearned for more flexibility (read: I don't want to have to recode this for every application!).
As with all epiphany's, what began as a little exercise in seeing where I could take it ended up consuming a couple days worth of development. The result is a plugin that will enable developers to specify any number of intercepts, using regex keys or path prefixes, to split url data off of a content-identifying url. For instance, if you had a page such as:
http://www.grantshepert.com/go/contact-us/
... you could create an intercept with the trigger "contact-us" and this link would load the same page:
http://www.grantshepert.com/go/contact-us/from-blog/comments/our-friend-coldfusion/
... with the difference that you could assign the three trailing 'pages' to variable names and assigned validation to boot!
I've also made it so that you can assign multiple 'keysets', so that you could have:
http://www.grantshepert.com/go/contact-us/from-blog/comments/our-friend-coldfusion/
http://www.grantshepert.com/go/contact-us/from-news/08/14/2009/
http://www.grantshepert.com/go/contact-us/redirect/clevertechnology.com/
And each will trigger its own set of variable assignments and validation.
There's a bit of cleaning up to do, and some more testing to ensure that the variety of ways you can configure urls in Mura will not break the intercepts, but so far all is working quite well. Version 1.0 (well, we'll call it 0.5 for now) will require that intercept configuration files are written manually, mostly because we'll be creating them internally or generating them automatically out of bigger applications, but eventually there should be an in-plugin editor for those as well.
I'm off to cfunited next week, so whether or not I'll have time to get it out this week depends strictly upon how busy the week becomes ... but I'll give it an honest try.

Aug 12, 2009 at 1:47 PM This sounds really cool, Grant! Let me know when it's in good enough shape to test out. Also, I think there may be a typo in your post. Where it says:
"...you could create an intercept with the trigger "about-us..."
I think it should say:
"...you could create an intercept with the trigger "contact-us..."
Aug 15, 2009 at 4:04 PM @Tony thanks for spotting the error; all fixed up. As to the plugin, the only caveat with it is that I haven't tested it in a practical situation, so until I get a chance to do this I'm not sure if the current configuration will work. I am adding a custom event trigger this week that should make it generally more useful, though.
If you want to give it a try, drop me a line (here or on twitter at @grantshepert) and I'll send you a version to test.