Presently, neither the preprocessor nor assembler is able to iterate over strings: ...each iteration c would take on the values "A","B","C",... in the first line.

Why? It would simplify some code/listing generation macros. Symbols are composed of byte array - why not have access to this array? Prior to 1.69.00 the preprocessor strictly operated on symbols, but now can do calculations. Hopefully, this has opened the door for another small addition - no interpretation of bytes should be made by FASM (ex. multi-byte codings).

In a not so ubiquitous manner, it is possible to iterate over a string with the assembler using the VIRTUAL + LOAD control directives, but another method might be desirable here as well (FORC?).

MASM has IRPC and FORC directives in this capacity.

(An alternate naming of IRPB/FORB would explicitly state byte processing - not characters.)

It may help to convince Tomasz if you can provide an example of where this is beneficial.

I already know that IRPC would be a nice addition, and I wanted to add it the same time as IRPS, but there are few decisions I had a trouble with, and since it wasn't a high priority addition, I suspended it.
For example, how should it behave, when fed multiple symbols after the comma - should it signalize an error, or just iterate over characters of the consecutive symbols? People with MASM background may expect "irpc c,2 +1" to iterate space as well, but with fasm it's impossible. To avoid confusion, perhaps error would be a better thing to do - and thus force using IRPS and IRPC in combination for such cases?

Current FASM symbolic handling should be respected: to iterate over space would require quotes or <>. Multiple symbols imply concatenation (yeah, kind of confusing).

Edit: I'm wrong about IRPS respecting <>: