Tried with fluid supplier and fluid request pipes - they do not connect to BioFuel Generator.
Ordinary waterproof pipes DO connect.
Could not find any other machine that behaves like that.

LP fluid pipes were able to connect to it in build 217 (I skipped builds 218-229)

LP build: 230
Modpack: FTB Direwolf20 1.0.23 (MC 1.6.4)

G.

it's a bit of a problem caused by fluid LPs really being item pipes that also happen to know how to handle fuids, and some MFR machines refusing to connect to item pipes.
Funny enough, that doesn't prevent fluid supplier pipes from working on them anyways:
Bug? Feature? Magic? You decide!

The problem rather is that this
https://github.com/RS485/LogisticsPipes/blob/mc16/common/logisticspipes/pipes/basic/fluid/FluidRoutedPipe.java#L48
is never called anywhere. How it worked all the time... I don't know. But the content of that method needs to be moved to the LogisitcsFluidTransportLogistics canConnect method or that code actualy needs to be called again.

EDIT: OK That was wrong. Stupid eclipse don't tell me the method isn't called when it is called...
But in general I would conside this a visual bug which should be fixed rather than not allowing the suplier pipes to work.

It worked because we claimed to be a structure pipe before 6441a6a

combined with

https://github.com/skyboy/MineFactoryReloaded/blob/master/src/powercrystals/minefactoryreloaded/tile/base/TileEntityFactory.java#L325-L338

and

        if (!(pipe instanceof IPipeConnectionForced) || !((IPipeConnectionForced) pipe).ignoreConnectionOverrides(side))
            if (with instanceof IPipeConnection) {
                IPipeConnection.ConnectOverride override = ((IPipeConnection) with).overridePipeConnection(pipe.transport.getPipeType(), side.getOpposite());
                if (override != IPipeConnection.ConnectOverride.DEFAULT)
                    return override == IPipeConnection.ConnectOverride.CONNECT ? true : false;
            }

in BC TileGenericPipe.canPipeConnect(TileEntity with, ForgeDirection side)

so basicly we are going to have to override the ConnectionOverride when we connect to MFR machines.

Yeah, but it also points to a different problem, we ignore overridePipe for getAdjacentTileEntities because we directly call pipe.canPipeConnect(tile, dir) and so ignore IPipeConnection.overridePipeConnection for determining adjacent inventories/tanks as that's only checked by TGP.canPipeConnect
so basically we have 2 options here.
a) implement IPipeConnectionForced on CRP and always return true for ignoreConnectionOverrides so we consistently ignore IPipeConnection overrides
or
b) have getAdjacentTileEntities use tile.canPipeConnect
b.1) implement IPipeConnectionForced in CRP, gt the adjacent tile, check if it's a IPipeConnection, and then depending on what kind of pipe we are (items, items/power, items/fluids, items/fluids/power) check if it wants to disconnect for some but connect for others, and if so override the override.
b.2) stop calling super.canPipeConnect from LogisticsTileGenericPipe.canPipeConnect and just do what it's doing ourselves, with the same special-casing to selectively ignore overrides as above but avoiding a bunch of duplication and spreading the code over 3 different classes.

TBH, I mostly feel like option a).

Reasoning:
The whole interface feels redundant.as Inventories can already not connect to item pipes by not exposing any slots on that side.
Similar for IFluidHandler and tanks.
For power there's getPowerReceiver(side) and canEmitPowerFrom(side).
The whole aspect of forcing a pipe to connect to you is just rude.
You can already make item pipes connect to you while not accepting items by... not accepting items.
For fluids it's exactly the same.
Forcing a connection to a power pipe... what would that even accomplish if you are not a power receiver or transmitter?
So the only new functionality the whole mess enables is... allow tiles to connect/disconnect from structure pipes?

Should be fixed in new dev builds.