I was not aware of that recommendation. Maybe the writer uses platforms with less resources.
The recommendation is pretty prominent on the main git page of +TCP
phyHandling.c is a well tested generic interface to 100 Mbps PHY’s. All you need to provide is two access functions for reading and writing.
Completely agree, and normally I would use it. This is not a standard PHY, however, and beyond that, we’ve implemented cable diagnostics.
I don’t know where files like “tcpip/tcpip.h” come from.
It sounds like you don’t need anything special in the BufferAllocation module.
I found the files - they are a part of Harmony. 
I like BufferAllocation_1.c as well, provided that I have enough memory. Quite often my network buffer memory is not cached, where the heap memory is cached. That has advantages when doing DMA operations.
Exactly why I’ve typically been using BufferAllocation_1.
Here is BufferAllocation_2.c without dependencies.
Compiling that file causes segfaults at vReleaseNetworkBuffer very shortly after startup - which is actually what lead me to the pic32 specific BufferAllocation_2.c
void vReleaseNetworkBufferAndDescriptor( NetworkBufferDescriptor_t * const pxNetworkBuffer )
{
BaseType_t xListItemAlreadyInFreeList;
/* Ensure the buffer is returned to the list of free buffers before the
* counting semaphore is 'given' to say a buffer is available. Release the
* storage allocated to the buffer payload. THIS FILE SHOULD NOT BE USED
* IF THE PROJECT INCLUDES A MEMORY ALLOCATOR THAT WILL FRAGMENT THE HEAP
* MEMORY. For example, heap_2 must not be used, heap_4 can be used. */
vReleaseNetworkBuffer( pxNetworkBuffer->pucEthernetBuffer );
Perhaps it would be better to investigate why the generic BufferAllocation_2.c seems unhappy with PIC32?
