Slic3r I gather does not yet have a Cool option.
I've done a simple Gcode post-processor which inserts cool sequences. (and can do other things)

But the sequence to run it is quite cumbersome in some circumstances, e.g. when using Repetier's very easy multiple object placements facility - the ordinary way is very convenient to just generate the Gcode and run -
but I have to go out, run my postprocessor, come back to repetier and reload the modified gcode.

It struck me it would likely be a very simple addition to Repetier Host,
to have an additional Config/RepetierSettings entry for "External Gcode post-processor". (plus a timeout value)

If the executable path was non-blank, then after RHost generates Gcode, either from the Object placement screen, or just from loading and slicing an STL, it would run a System call to the external program, passing the path to the current gcode file.
It would then wait for the sub-process to return (or timeout based on the preset timeout value),
then use the processed Gcode file.

This approach would of course not be specific to slic3r, but allow very flexible customisations to gcode from any selected slicer.

I really like your ideas. If you tell them I could say, why didn't I think of this before. With time I will include this. Looks like my todo list is growing and growing -) Filters are cool and there are many ways I could implement them. So just a few thought what could be done.

1. For non programmers: Add a Layer start/Layer end editor page that will be inserted between layer switches.
2. Define a list of filter programs. Theses filters can be called manually.
3. Insert filters to a printer configuration. This time all objects sliced in this filter will run the filter after slicing.

Each filter has to read a file and write into an other file. If you have more then one filter, they are called in the order they are listed,

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

and I really like your program(s)

Generalised filters are a good longer term goal - creating a mechanism for non-programmers will be - um - fun but time consuming ...

A single filter call (#3) for programmer-users will be easiest and should therefore be at top of that list