Actually, after my last realization about how parameters should be implemented, the minimal necessary tweak is to add an alternative to with-continuation-mark to (srfi 157), and for the implementation of parameters to use it and for (srfi 155) to use it when setting the tail-call-detection mark. Then no changes to (srfi 154) are needed.
(with-unique-continuation-mark <key> <value> <expression>)
The name may not be ideal. This will add the given continuation mark, and remove all other marks associated with the same <key>. (For the purposes of limiting space growth, it MAY be sufficient if this removes at most 1 other mark associated with the key -- that would still pass all the standard lazy streams tests, but I can't for certain say it's the correct approach. I can't think of why someone would mix the two flavors of with-continuation-mark on the same key -- just looking for trouble, I suppose).
So, then the sample code for parameterize should use this, as well as the sample code for (srfi 155) when setting the tail-call-detection mark.
2) You argue that we can save space by treating, continuations as lists (instead of copying them). However, on several occasions, you are filtering lists of marks. Don't you have to copy the lists for this?
It's not my intent to suggest that Scheme systems with entirely different approaches to continuations cannot get the space-growth issue right. I just haven't had the time to fully explore these issues in other systems beyond my own. I *think* the change I have proposed is necessary across all systems, because with-continuation-mark has necessary consequences on the results of other (srfi 157) API which requires growth in storage.
It's true that in my code, I can walk the "list" of continuations, and attached to each continuation is a continuation-marks list (which is lazily constructed only if needed, but never, ever mutated after that).
The proposed new (srfi 157) item does, in general, have to do some copying -- though it's certainly encouraged to share common-tails. This doesn't create a new source of space growth though -- since as all the old continuations become garbage, their associated marks lists become garbage as well.