quoting Rhetorica:

quoting dhok:

One idea is to have an entry field for strings of characters that must be treated as single characters. Using Zompist's SCA, I've often found myself resorting to such extravagant representations as Devanagari characters for phonemes that the Latin alphabet has trouble representing easily.

This SCA could set aside a block of rarely-used Unicode characters- say, Yi syllabics- and replace each string in this block with a character from this block. (The nice thing about computer programs is that they can automatically replace and read characters that humans can't easily type or interpret). It will do the same with strings in the rule file as it runs. Then, at the end, it converts them all back. You're still working with one phoneme = one character, but the human doesn't have to mess around with special symbols.

This is, in fact, something I had planned on for klank, our on-site SCA. Syllable-finding, too. However, it is a pain in the ass to write an SCA, so I'd really prefer it if Morrígan could just add every feature everyone's ever requested to hers... but, hey, y'gotta make do.

For Dhok's idea, we can already do this (almost). IMO, the most difficult thing about basically every SCA is that they don't understand that pʰ is not just a sequence of p+ʰ it's a separate, single symbol. My programs doesn't manipulate strings. It does a bunch of work up front to turn strings into sequence objects, which are an array of segments, which in turn hold a string/symbol and optionally, feature data. So, during the segmentation it's still possible to have character sequences reserved.

For the example with Ps, I'd have to agree that it seems like a simple order-of-operations mistake, but I think the standard formalism for sound changes is perfectly sensibly and I don't (personally) see it as contributing to this problem. If you understand what you want clearly, and pay attention to the feed and bleed orders, it's fairly simple.

Hallow: no need for anything extra: p_h p b > p b p should work for that because of the way the rules are applied. At least in theory - this is a bug I'm working on, looks like the cursor isn't advancing through the word correctly in this case.
Fixed it! There was a dumb quirk on the way I was advancing the cursor.