Having reflected on this a bit more, I don't think the fourth point makes sense, and I'm also a bit unsure what problem it's trying to solve.

• The main problem in theory, as I understand it, is with identifiers that would be used in URLs and break stuff as a consequence (e.g. datastore.com/my-iati/identifier). There's already a way of handling this by percent-encoding a URL: http://en.wikipedia.org/wiki/Percent-encoding
• I can also foresee this causing some issues where an organisation has internal project codes that use any of the forbidden characters (e.g. UNOCHA, ECHO, MCC, etc.). The current guidance for constructing an iati-identifier seems to be sensible in taking whatever code is unique within an organisation and prepending it with the organisation identifier.
• An organisation could get round this by finding forbidden characters and replacing them with allowed characters, but it seems a little unnecessary to tamper with the data in this way.

Instead recommend:

• Add guidance to developers to encourage them to percent-encode any iati-identifiers passed around as strings, including forward-slashes: http://flask.pocoo.org/snippets/76/
• Warn both developers and publishers that using non-ASCII characters (like ä ö, etc.) could cause problems in iati-identifiers if the document uses an incorrect character encoding (this is an issue that applies more broadly anyway, I think)