Currently all filters are hard-coded into dust.js. Helpers can be user added and this is a supported extension point. Filters are useful for a different set of problems than helpers and could easily be made user-extendable in much the same manner.
I would suggest that filter names of the form x- be designated for user-extensions leaving the rest of the namespace for language expansion. Otherwise we would always be facing a backward-compatibility risk.
To increase the flexibility I would suggest passing context on down to the filters as mentioned in Issue 204. This gives them more flexibility. A benefit of filter extensions is that the resulting object can still be passed as a param, etc unlike when a helper is used.
@jimmyhchan is working on this, as we realized the need for extensions to filters for html and js encoding.