[ I posed this as a comment to the CurseForge page for the mod, but thought it might be better discussed here even though it's not really an issue. ]

I've been playing with the pipes, and this seems to be the way they work. Please correct me where I am in error or missing a piece of the puzzle. I'd like to do a tutorial video for this mod.

Using the basic Item Transport Pipes, you need to use Extraction Pipes to remove items from an inventory and put them into the pipe system, and then have Injection Pipes on inventories to give them somewhere to go. The items will enter the pipe network even if they don't have anywhere to go, stopping in the last pipe that could possibly have accepted them and sitting there. Both types of these end pipes take up a full block space on their own.

(The Source and Destination pipes don't interact with inventories when used with the basic Item Transport Pipes. If they have a purpose with basic networks, I haven't found it yet. And if they don't, they probably shouldn't even connect to basic Item Transport Pipes and cause confusion. )

With the Advanced Universal Pipes, everything is different. The end pipes are attached to the Advanced Universal Pipes instead of being their own block. Also Item Filters are needed to make them active.

There are two arrangements of Advanced Universal networks possible. The first acts similar to the basic network setup with items being forced out of an inventory into the pipe network and then exiting at the first inventory that will accept them. The difference is that the items aren't removed from their initial inventory unless a valid inventory is available to take them, then they travel instantly. For this setup, Extraction Pipes do the pulling from inventories, and the Destination Pipes mark where the items can go.

The other way to use Advanced Universal Pipes is to have inventories asking for items that are held elsewhere. For this, the Injection Pipes request items for their connected inventories and Source Pipes mark the inventories that have the items.

Both Extraction->Destination and Injection<-Source paths can be attached to the same Advanced Universal network, and they won't interact with each other.

So...

Question: Do the Source and Destination pipes do anything with the basic pipe networks, or are they only for the Advanced pipes?

Suggestion: The Injection pipe's name works okay (but not great) for the basic pipes, but doesn't reflect the pipe's function with advanced pipes. A better name system might be to have "Extraction" and "Destination" pipes work together for both basic and advanced networks, then have "Source" and "Requester" pipes paired up for advanced-only networks. I think that would be much more intuitive for the uninitiated. This would split the dual function of Injection pipes into two. But it assumes that Source and Destination pipes aren't useful with basic networks.

did you ever make a mod spotlight? Is there another source of information for this mod?

Source and Destination pipes have a use in basic pipe networks:
They provide start or end points for the path that items move along in the transport pipes. This is useful because all the basic pipes have an internal inventory (one ItemStack or one Bucket of capacity) that machines can interact with.
You can even have Injection/Extraction Pipes insert to or extract from another pipe (threating it as inventory) by sneak-right-clicking on the other pipe's half of the connection between both pipes (so the Injection/Extraction pipe still still shows a connection to the other pipe but the other pipe doesn't show the counterpart).

Another thing: Extraction Pipes, Injection Pipes, as well as all pipes attached to the Advanced Pipes can be turned ON or OFF (the red cross marker) by right-clicking on them with an empty hand. So the advanced pipes can be operated without filters, you just need to activate the connections. Pipes are always active when a filter is applied (or rather the redstone setting of that filter controls whether they are active) and pipes get automatically deactivated when taking out their filter. This is meant to prevent unwanted (unfiltered) item transfer while changing filter configurations or performing other maintenance work on the pipes.

There is also a hidden feature that isn't documented yet:
When a transport pipe has multiple connections that would provide a destination (either Destination or Injection Pipe at the end) it will only choose one of them (indicated by where the green arrow points to) but when a redstone signal is applied it will flip over to the other option, or if there is more than one other option (> 2 outputs in total) the strength of the signal defines which of the other options is taken. Turning the signal off again makes it return back to its original choice.

Ah! Good information. Of course, now I have to throw out the video I just made as it has some incorrect, or at least incomplete, information. :)

I just did a test and a destination pipe above a hopper that's pointed at a source pipe definitely is a thing. Okay. If there are any other tidbits, I'll try to incorporate them. I'm going to go set up a full mod showcase this time instead of a small test setup.

I guess I'm still not sure why the Ex/In/Src/Dst pipes behave differently between basic and advanced networks—mainly the Injection pipe. It works with the Extractor in basic, but not in the Advanced. Might be a bit confusing to people and I don't have an explanation to give them.

I have some tips and tricks for you (if you haven't already found out your self): The Portable Inventory Remote Access is very useful to see (or demonstrate) what is going on in Inventories especially those that don't provide their own GUIs for access, like Item Pipes, the Dropped Item Interface, Entity Interface and Item Placer.
As you said you're planning a full mod showcase: the Remote Access Pipe recently seems to be a commonly misunderstood feature so it would be very helpful for to show it off, too:
These pipe blocks behave as if they were the block they are connected to. Essentially all interactions with the pipe's inventory, fluid or forge energy capabilities are just forwarded to the block at the end of the line.
Starting from the target block these pipes can be spread and branched out as far as one likes (the green marked connections will point towards the target). So one can have any amount of devices interacting with any of the pipe blocks which will cause them all effectively interact with the target block instead, using up only one of its block faces. Also directions are preserved in a way that interacting with the pipe from the top will also forward that interaction to the top of the target no matter from which side the pipes is actually connected to it. These pipes are especially useful to extend the reach of Automatic Crafters when chaining them together for more complex autocrafting processes.

Also they can be covered like all the other pipes which makes them perfect for hiding complex cabling of machines behind walls.

Oh and about the Ex/In/Src/Dst pipes: I would explain it as the Source and Destination Pipes are passive whereas Extraction and injection Pipes are active. In basic pipe networks the Ex/Inj pipes actively transfer items/fluids with inventories while with Src/Dst the machines or external devices have to do the work. And at the Advanced network the Ex/In pipes again actively perform the transfer while Src/Dst only tell them where to put/get the resources. Since the Advanced Pipes have not internal storage, machines / external devices can't do the active interaction there.

The destination pipe has a solid green band but the source pipe’s red doesn’t cover the corners. Oversight or design?

Extraction (Filter: whitelist cobble) -> Advanced -> Destination (Filter: whitelist cobble) WORKS

Source (Filter: whitelist cobble) -> Advanced -> Injection (Filter: whitelist cobble) FAILS

I expected the second case to work. The Injection asks for cobble and the Source can provide it. What is wrong with my expectations here? To make it even more confusing, flipping the Source’s filter to blacklist cobble lets it through.

Fluid filters don’t seem to want to go on the fluid I/O pipes by default. You have to change something on them first, like toggling black/white list on and off again.

Also, the Item Placer seems to have some troubles. I have one hooked to a Buffer (tried both basic and Advanced piping) and put a stack of concrete in the buffer. The Placer put one block in front of it, one to the side of that one (to the south), and then there was a third placement sound effect, but the block remained inside the Placer. (It drops when the Placer is broken.) Removing the blocks does not cause it to place any more. When facing upwards, it placed two in a row and kept the third in the same way, no longer functioning when the placed blocks were removed. If it’s output area is confined to just one block, there are two placement sounds and the second block gets stuck inside the same way.

Entity Interface doesn’t work with player inventories by design for security reasons, I presume.

Minecraft freezes (tight loop?) if you place a Remote Access Pipe under a hopper (aimed at the pipe) and then break the hopper.

I had a furnace connected to a line of RAP. At the other end I had three hoppers: one on top to feed in ore, one on the side for fuel, and one below to pull out the ingots. When I broke a pipe in the middle of the chain, the link was broken, so I broke all the RAP and started a fresh chain from the furnace. But placing the last piece between the hoppers wouldn’t connect to the rest. It connected to the hopper above it. So I broke that hopper without breaking the RAP first, and the game locked up.

[ Sorry for all the questions and such, but if I’m going to do a mod spotlight I want it to be accurate and comprehensive, and paint the mod in as good a light as possible. :) ]

Would you like me to make separate issues for the backwards filter and freeze crash?

Sorry due to notification issues I fell behind a bit with all the questions. So keeping up again:

• For the markings on the pipe textures every pixel is intended:
  Source Pipe has red arrows pointing outwards (looks like a ring), Destination Pipe has green arrows pointing inwards (looks like just corners), in general green is a destination/output and red is a source/input, Extract/Inject Pipes just have the arrows inverted so rather indicate their interaction with nearby blocks. For Source/Destination Pipes on advanced pipes they show a large and a small stripe forming a pseudo arrow that points the direction (might be hidden behind the red cross marker).
• Strange Filter Behavior in Advanced Pipes:
  Yes the filter acts inverted for sources on advanced pipes, maybe that was a bad idea due to the confusion it could cause. But the reason for that was that I once planned a pipe connector that is both source and destination at the same time and would use its filter normal for items going into the attached inventory and inverted for items taken out of it. I'll probably change that to only do this special case behavior on the new connector type and not on normal source connections (I'll open an issue for that on my own).
• That the fluid filter didn't work before opening the GUI once might be because the Filter's NBT-tag wasn't initialized so the pipe didn't accept it. But this shouldn't be a problem since using unconfigured filters usually doesn't make sense (default setting won't accept any item at all).
• The Entity Interface generally can interact with player inventories but you cannot open a Portable Inventory Remote Access linked to it if that would access your own inventory. That is a protection on the Remote Access device because there were otherwise some issues in the GUI when shift click transferring items between your inventory and ... your inventory (automatic transfer by filters works although being quite pointless).
• The Item Placer doesn't just place blocks, it right-clicks the inserted items against the the block in the target location (block in front if no redstone applied) or places them into that location if the spot is empty. The placement orientation is simply cloned from how you right-clicked (empty hand) the block the last time (this includes sneaking status, your relative player position and look aim). So in your case the first block inserted was placed into the empty spot, the second was placed against the side of the existing one the the third could not be placed because the side spot was already occupied so it was left as remainder in the inventory (as the tooltip said: remainders must be extracted before next operation can be performed).
• The freezing bug with the remote access pipe is better put in a separate issue like you already suggested.

Another thing: I noticed that you send me a private video, unfortunately gmail failed to open the notification Email (it just keeps loading forever without network activity) and I couldn't find any access for it on youtube itself. Maybe it works if you send me the link for it as PM on curse forge.
I was able to open the Email now, but the video seems to be nonexistent.

I had an Entity Interface hooked up to pipes that would empty it into a buffer. When a chest cart goes in front of it, the cart is emptied into the buffer. But when I stand in front of it, my inventory is unaffected. That was the basis of my assumption that it does not work with players. I did not turn the pipes around to se did it could push into my inventory.

Oh, and I sent that PM on Curse with a new link that should work.

The Entity interface is side sensitive so accessing the block from different sides may access different parts of the Entities inventory or tanks depending on its implementation. And the way Forge has implemented the player inventory capability is: bottom and top give access to the main inventory and the sides give armor and offhand slot.

Aha!