This is an intentional feature.  See:

src/bookmarks/ephy-bookmarks-menu.c, line 277:

        folders = g_strsplit (title, "/", -1);

Personally, I like /.  You're not allowed to have 'os/2' as a directory on the
filesystem, so not being able to have it here doesn't seem too unreasonable to me.

Maybe there could be a workaround that lets you have a / if you escape it
somehow?  This could get ugly.  What other character would you prefer?

The filesystem is a completely different beast than the bookmarks database; so
that argument is moot. There's no need to bother the user with filesystem
intricacies.

Furthermore this introduces a regression, also reported in
http://mail.gnome.org/archives/epiphany-list/2004-August/msg00006.html . The
slash was allowed in the past and people have topics with slashes in them which
are broken by the current code. This is true for every other single character
separator you could come up with.

So I would propose a character sequence, for instance {/}. If the slash is
retained as separator, at least the effect of breaking peoples topics should be
prevented.

The user is exposed to the fact that they can't put / in a name through Nautilus
(and every other app that creates/saves files).

The idea of using something like {/} seems sort of awful.  I think the real
solution is to create a real hiarchy for topics. (ie: in the topic sidebar of
the bookmark editor you'd have a tree.)  This seems like a lot of work and
probably involves API changes.

It won't happen soon, and it might never happen.

Bookmarks != files. The fact that the filesystem is exposed in some places where
it /has/ to be, is not an argument to artificially impose the same limitations
somewhere else.

Topic hierarchies sort of defeat the point of topics. All we're talking about
here, is - as far as I know - a hack to accomodate imported bookmark hierarchies
from other browsers.

I agree that in retrospect '/' seems like a bad idea as its too common. '->'
seems ok. Or we could do something (like "*SUBTOPIC*") which would be extremely
unlikely to ever show up, though that may not be worth it as its long and would
make imported bookmarks awful. Maybe '~>' ? Would be very rare, still sort of
human readable, and is short.

The nice thing about "/" is that somebody could think to himself, "Hrm, I'd like
to make this a subtopic Y of the topic X... I wonder if I can do it with
'X/Y'?"... and it would Just Work. In other words, it would be the most common
first guess as to how to make subtopics.

Then again, if we are trying to *hide* the subtopic feature in Epiphany (i.e.,
discourage its use, not expose it except through bookmark import), "/" is the
worst possible character to use.

If we're going for a compromise, "|" seems to me to be a good character to use
(who would put "|" in a topic?). It's memorable enough that people won't have to
look at Help each time they want to make a subtopic.

First I didn't like the topic approach, but once I used it, I realised that it 
is a great, object oriented approach - and it seems that possibly other 
browsers are going to switch to it ( e.g. someone is working on it for 
Konqueror already ). But now you want to implement a dirty hack to support a 
broken kind of hierarchy again ?

My proposed solution :

Has anybody tried Peter Harvey's bookmark patch ? 

http://mail.gnome.org/archives/epiphany-list/2004-August/msg00017.html

This should be the default behaviour. As for the import of hierarchy 
bookmarks : Do the reverse thing as Peter Harveys approach : Every hierarchy 
level of an imported bookmark is a topic.
That system needs to be elaborated so that import, display and export of topic 
bookmarks resolves to the same set of bookmarks under all circumstances, even 
when importing from / to hierarchy bookmarks ( ordering exclusive ). If this 
will be achieved epiphany's bookmark system will be a perfect, object oriented 
bookmark system - without hacks.

Or am I wrong ?

I agree to Norman's comment. However I think Pete Harvey's patch won't make it
to Epiphany 1.4 (GNOME 2.8) because of feature freeze. And I don't know if
having yet another way of handling bookmark imports in 1.6 is really worth it...

Fixed in cvs.

*** Bug 151804 has been marked as a duplicate of this bug. ***