Is your feature request related to a problem? Please describe.
Currently, the whitelists and blacklists basically work fine, as far as I can tell, but they seem to confuse a lot of people at first, including me. It wasn't until I realized they were backwards that they made sense.

Right now, the default whitelist implicitly contains everything. I hope that makes it a little more clear where the problem lies: it's not a whitelist if it isn't explicit. If you switch modes, the default blacklist also contains everything. Adding a single item to that list of everything basically does nothing. It's only if you add something with an inverted filter that it becomes meaningful. Now we're whitelisting everything EXCEPT this item...

...but at that point, what you have is a blacklist. So the functionality is all there and fine, it would just be a huge UX win to swap things around.

Describe the solution you'd like
The current default should be displayed in the UI as a blacklist with nothing on it. The icons/labels could just be switched; it would function the same. Items should default to their current "inverted" form: adding an item to the default blacklist should be the same as currently adding an inverted item to the default whitelist, which will make that item not pass the filter. If the mode is switched to whitelist, then all items should be blocked except added items. "Inverted" items should only be needed then to carve out exceptions to other filters, and not routinely.

Describe alternatives you've considered
This doesn't seem like it should be too difficult as a code change because it's really not that different from the current behavior. Simpler, possibly: Change the filter mode label to "Default Mode: Allow/Forbid" (or All/None or something like that) that is more accurate, and then make new filters default to the inverted state, so that adding an item in either mode will, by default, give you a useful filter. But I think labeling them as "inverted" is still going to create confusion.

Yes, the current implementation is terrible from a UX standpoint and I can't even get it work how I want. I just want it to pipe different ores to different chests and I cannot get it to work. Weirdly it seems to work with 1 chest, but as soon as I introduce destinations, it doesn't know what to do and just starts piping everything everywhere.

I thought I could do something basic:
Chest of ores -> 1 pipe -> 3 chests
Apply a whitelist and add ores with the destination set of the chest I would like them to go to.

But I cannot figure it out, it either puts everything everywhere or nothing anywhere.

Adding this as per henkelmax, basically an :

Is your feature request related to a problem? Please describe.
When attempting to set up the most simplistic filtering system for an auto-crafting setup, the current filtration system doesn't require the pipes to enforce destination based on distribution. In order for this not to be the case, all possible destinations must be equal in distance from the pulling pipe, so that the destination is weighted by the filtering. However, this type of logical interactions don't really make sense when setting up a large auto-crafting system designed for a large number of processing via different types of machines whereby multiple machines might be able to accept the item being delivered.

Describe the solution you'd like
If I set up an item to be delivered to a destination, I want it to go into one of (if not the) specified location(s). Along the travel path, it should ignore and other inventories where it might be accepted, even if those are closer/further based on the distribution mode. In essence, this would be the creation of another distribution mode where the item only goes into the location for which it has been specified.

Describe alternatives you've considered
An alternative to enforcing the filtering system would be to add a new filter that can attach to a "pushing" pipe that is going into an inventory. This would be similar to upgrading the pipe as it is done via pulling, but instead would allow you to simply add a specific filter to the destination itself. Then when an item is traversing the piping paths, it would acknowledge the whitelist/blacklist and move into the destination or move to the next one if it can't.

The pitfall to watch out for here is when there is no valid inventory to deliver to when all locations are blacklisted and the item traverses the end of the pipes. At this point, it would probably be best to either "void" the item, or pop it from the pipe into the world itself.

Additional context
In addition to this, a side suggestion for the destinations.
Currently, simply right clicking a block sets the destination on the filter tool. This makes it rather tedious when you are (again) dealing with a complex system with multiple devices capable of processing or handling an item. Thus, it would make sense to allow the filter destination to carry multiple destinations, in addition to the first one.
Example:
Right clicking -> Clears the current destination list and starts a new one beginning with the block clicked.
Shift+Right clicking -> Adds the block clicked into the destination list

Using the above example, you would then be able to provide multiple destinations to send an item to. Handling it on the pipe side could be done two ways.
1 - Loop through the destinations and create individual rules for each one when clicking submit (This preserves the current handling, and allows you to simply loop through destinations to create rules)
2 - Allow a filter to have multiple destinations (This does not preserve the current handling because it requires a bit of logic changing in how destinations are perceived)

It's not to do with the destination feature per se, but it does pertain to the allow/deny-list, so I hope this is the right place.

Is your feature request related to a problem? Please describe.
The filter lets you use tags. Tags, of course, can match multiple items. My problem is that I want to move almost all items with that tag into one location, and just one of the items with that tag either need to stay in the connected inventory, or go to a different location.

Let's say I have a bunch of Hopper Botany Pots with Mystical Agriculture plants in them. I collect all the items they generate, and want to pipe all the seeds (#mysticalagricultue:seeds) into a Seed Reprocessor. This block accepts all items, not just seeds, and then blocks / stops working (as it can't do anything with items that are not seeds). So, I need to filter it. So far no problem. However, I'm short on, say, Nether Quartz Seeds, so I want to process (read: filter) all seeds except Nether Quartz Seeds.

Describe the solution you'd like
Have a priority assigned to the filter items (it looks like it's already a list with an internal order as closing and opening the UI doesn't change the display order, so "all" it needs are buttons to change the order) and decide per item on the list if you want it to be an allow or deny entry. Or, alternatively, again, priorities, and have the destinations work like @MagisterXero is proposing (only go into that destination, regardless of other options).

Describe alternatives you've considered
I could add each item that matches the tag individually and not add the item that I don't want. It works, but it's quite cumbersome and not really scalable.

I also found this thread when about to write a bug report about how filter just does not work. Either it puts things in the nearest inventory, even if I manually attempt to tell it to not put it there, or it just doesn't put the thing anywhere. Doesn't seem to matter what combination of black/white regular/inverted I use... I can use white list with a regular telling a fluid where to go, and an inverted telling it where not to go and it doesn't make any difference. It still puts it in the nearest inventory. I can put a single inverted on a black list and the thing won't go anywhere. I've spent hours on this and have only determined that the pipes are unusable for any setup where things need to go to a specific location and not others. Would really like to see the ability to have things go only where they're set to added. This would be even better if done at the destination rather than where it's coming from.

Bump. I've spent a good amount of time trying to setup simple 2 chest split filtering system with no success and ended with using logistical sorter from mekanism instead.
An enhancement or proper guide on filtering would be appreciated.

Has this topic made any progress? This thread is pretty old now and this is still an issue in v1.2.6.

Yeah I couldn't agree more. Just downloaded the mod to figure out, if its the right thing for our server (IT IS!). Build a little furnace array... all fine. Then i tried to do some item sorting, but I couldn't get it to work:
Mode is whitelist.. so only items that are on the white list, should be passed. Added a destination for (e.g. for coal), but the coal always went to the nearest chest (as set).... but all other items that i put into the chest get transported... which should not happen, since they are not on the whitelist.
Now... as described... you can get it to work, by enabling blacklist and inverting the filter... but this is just not how blacklists and whitelists work.

It should be like this:

Whitelist: Only items in the list should be processed
Blacklist: All items, except the blacklisted ones should be processed

Blacklist should be the default imho.

I was just about to write a bug report until i noticed this thread / issue. :)