Rather than Page Name, we can just be fully explicit about it, as is done for the Group Name, and call it the Page Address:
This makes it quite clear what happens if you change it, so like a group name it wouldn't have to actually be permanent. Changing it will have understandable consequences.
In any list where one can select a page it would be best to show both the Address and the Title, in the same way that the entries in the Publicly Listed Groups show both the Address and Title on the first line of the entry.
I'm not sure what the actual list of excluded characters should be, but I'd want to avoid things that must be encoded when displayed in a browser address bar.
One way to handle backward compatibility with existing pages would be to continue treat Titles as addresses also, an alias for the same page. When creating or editing a page one would not be allowed to use an existing Address or Title in either field. The only downside I can think of is that it carries the title-based addresses into the future indefinitely.
Another approach might be to give each existing page a serialized initial Address, with the title-based URL as an alias for that existing pages only. This would avoid breaking links while also not creating new aliases (title-based URLs).
So I guess those are two versions of my wiki permalink suggestion:
1) Treat wiki pages more like messages and assign each a serialized page number as its permalink address.
2) Treat wiki pages more like group names and allow the user to assign each a semi-permanent Address that is distinct from its human-friendly Title.
I'm not ignoring Mark's (3) "Treat the Title with more ceremony, like Wikipedia" version. It just doesn't seem as "natural" to me as making the Wiki pages more like something else that Groups.io already does.
I like the mnemonic value of (2), with the primary downside that it creates a little extra friction that might cause some timid users to shy from creating a wiki page ("I have to think up a good Address too?"). Plus it is another field to explain and have group rules about.
On the whole I think I prefer the simplicity of (1), even though it has the downside that everywhere you pass a link to the page the URL itself won't say what the page is about, you'll have to do that in text.