I think enabling /aline, /rline, /cline, /dline and /iline to work on #channel windows can have some useful purposes. Easy things would be correcting errors (applying the correction* or s/bleh/blah/ lines for example) or changing/merging lines when there's a netsplit or mutiple joins/quits/parts.
To do these things with scripting,
-> you either have to make a new custom window, hide the #chan window and then catch all relevant events and write them yourself,
-> or script a 5 minute buffer so you can write out the 'corrected' text to the #channel window. You still have to catch all possible channel events to buffer them, and you get 5 minutes 'lag' in that channel, while still not catching everything you want on quiet channels...
The other thing I want to put up for discussion is some way to add information (ie line of text) to lines in a custom or channel window. It wouldn't display, just make and extra prop for $line, something like
$line(@custom,1).info. There you could append extra information for that line, or the same information but better formatted for parsing

For example, in channel windows you could put the timestamp so you don't have to display it always, but in some cases where you need the time, you can still get it rather easily. Other things could include your away status at the time of the message or some kind of level or rating information, so that you can later select only lines of a special level. And I guess you people can find more uses for it

especially in combination with the first suggestion.
As for implementation, just adding a pointer to each line does not seam like much overhead (compared to the line itself) when this feature is not used. Just make sure the memory is freed when the line goes out of the buffer if it's actually used