I think I have an idea what is going wrong with this.
I checked the CVS history, and I think the problem is this change:
Revision 1.173: Replace non-ASCII character in regular expressions with ~
Diffing the code, I see this:

 diff -u b2evolution-4.1.0/blogs/inc/_blog_main.inc.php b2evolution-4.1.1/blogs/inc/_blog_main.inc.php 
--- b2evolution-4.1.0/blogs/inc/_blog_main.inc.php      2011-09-08 18:05:45.000000000 -0700
+++ b2evolution-4.1.1/blogs/inc/_blog_main.inc.php      2011-10-03 11:01:39.000000000 -0700
...
-       $blog_baseuri_regexp = preg_replace( '¤(\.php[0-9]?)?/?$¤', '', $blog_baseuri );
+       $blog_baseuri_regexp = preg_replace( '~(\.php[0-9]?)?/?$~', '', $blog_baseuri );
        // Read possibilities in order to get a broad match:
-       $blog_baseuri_regexp = '¤^'.preg_quote( $blog_baseuri_regexp ).'(\.php[0-9]?)?/(.+)$¤';
+       $blog_baseuri_regexp = '~^'.preg_quote( $blog_baseuri_regexp ).'(\.php[0-9]?)?/(.+)$~';

I think the problem is the ~.
My URL is http://localhost/~jfeise/blogs/...
So I think that the change operates on the ~ instead of using the ~ as pattern delimiters in the preg_replace and preg_quote. That may have been the main reason to use a non-Ascii character as delimiter.
The "unknown modifier 'j'" stuff would be the result of the 'j' being the first character after the ~ in the URL.
I'll revert this in my code tonight to see if that's really the issue.

I verified that this, using the ~ as delimiter, is indeed the cause for this problem.
Please select another character, one that is not as likely to appear in an URL, as delimiter for the regex pattern matching.

Thanks for pointing this out. We need to change the character indeed.

What happens if you add ¤ char to the URL? Not that it's a common char in URLs but still... it will break the regexp

What we really need to do is escape delimiter char:

$blog_baseuri_regexp = '~^'.preg_quote( $blog_baseuri_regexp, '~' ).'(\.php[0-9]?)?/(.+)$~'; 

Well, a ¤ char is not a valid character in an URL.
RFC 2396 Appendix A specifies the BNF for URIs, including the allowed characters.
Other characters would have to be escaped with % hex hex.

RFC 2396 Appendix A won't stop me from pasting ¤ into the address bar and hitting enter ;)
Escaped delimiter will not break the regex, no matter if it's ¤ or ~

Fixed in CVS

sam2kb wrote:

RFC 2396 Appendix A won't stop me from pasting ¤ into the address bar and hitting enter ;)

Well, sure. But don't expect the web server to even give it to b2evo ;)
Most likely, the web server will bail out before it hits b2evo. They do a bunch of sanity checks, for security reasons. Nothing worse than a buffer overflow due to bad characters in the URL...

What I mean is it's perfectly safe to use any delimiter character if it's escaped. That's what the second parameter in preg_quote() function is used for.