I don't think there is much sense in such discrimination and hardcoding any plugins to be "system" ones. I would just warn users and then let them shut themselves in the foot if they decide to remove some needed plugins from the chain in configuration.
Date remover should not simply remove any found date within the log line. Otherwise, if the logline has timestamp elsewhere than the beginning, and some user-input upfront of it, abuser can pollute the logline with errorenous or misleading date, so that line is not caught by the filter, thus no action is taken, thus DoS or who-knows-what attack can proceed further providing such misleading entries.
At first I was thinking about "tagging" date position within the failregex line, but that might be tricky, that is why, and since virtually all log lines we are dealing with up to now have the date first in the line, I postponed it.
Also, 'prefix remover'-removed part might be desired for matching too.
What I am aiming in my comment is that all parts of the line should be considered in their entirety to some extent. IMHO it might become necessity that we could use result of previous plugins in the current one - like failregex matcher. But that complicates things...