I doubt this will break a significant amount of code. The restriction was removed 5 months ago and AFAICS it was removed to allow email addresses as IDs. That use case will not be broken if we disallow again IDs starting with '@'.
It seems that you can reasonably easily apply the "@" restriction in your own app code under 2.8 and 2.9 until we get around to doing the "right" thing by making this pluggable via the namechooser thingy, no? I dunno. The current set of restrictions is too restrictive for "real world" use when you use Zope heavily as a "fileserver", say via DAV. I wouldn't treat the existing or older restrictions as "gospel" as a result. I had actually been meaning to get around to unrestricting the set of identifiers in the trunk. Here's my current monkeypatch to Zope to unrestrict a good number of characters: def patch_objectmanager_badid(): """ Causes Zope to be less restrictive in the set of characters it accepts as valid within object identifiers. Added as acceptable: []*'!:@&#=+$ """ import re acceptable = r'[^a-zA-Z0-9-_~,.$\(\)\[\]\*\'\!\:\@\&\#\=\+\$ ]' bad_id = re.compile(acceptable).search import OFS.ObjectManager OFS.ObjectManager.bad_id = bad_id The projects that use this patch have been in use for several years; they predate Five. I of course don't mind continuing to do this, but I'd hate to have to change it temporarily (to fix this bug which actually isn't a bug for me because I don't use Five for these projects) and then change it again when we do the pluggable thing. I suppose I wouldn't care if the change was isolated to the "bad_id" regex, given that I replace it anyway. - C