In many implementations, NULL is just a #define for an integer literal 0, eg:

#define NULL 0

You can directly assign a literal 0 to any pointer, which is why passing NULL directly to the target function works fine.

Since you are passing NULL to a template parameter, that parameter is being deduced as type int, as the error message says.

In this call:

awrap(handlepath, handle, path, NULL, 0, coll, NULL);

awrap() will resolve to something like this:

auto awrap(decltype(handlepath) &func, decltype(handle) arg1, decltype(path) arg2,
    int arg3, int arg4, decltype(coll) arg5, int arg6)
 // ^^^^^^^^                                 ^^^^^^^^
{
    auto code = func(arg1, arg2, arg3, arg4, arg5, arg6);
    //                    error: ^^^^       error: ^^^^
    ...
};

To assign an int variable to a pointer, you need an explicit type-cast, which you are not using.

Whereas nullptr is of type nullptr_t, which can also be assigned directly to any pointer. There is only 1 possible value of nullptr_t. So, when passing nullptr to a template parameter, that parameter will be deduced as type nullptr_t. And the compiler knows how to assign a nullptr_t to a pointer.

In this call:

awrap(handlepath, handle, path, nullptr, 0, coll, nullptr);

awrap() will resolve to something like this:

auto awrap(decltype(handlepath) &func, decltype(handle) arg1, decltype(path) arg2,
    nullptr_t arg3, int arg4, decltype(coll) arg5, nullptr_t arg6)
 // ^^^^^^^^^^^^^^                                 ^^^^^^^^^^^^^^
{
    auto code = func(arg1, arg2, arg3, arg4, arg5, arg6);
    //                       OK: ^^^^          OK: ^^^^
    ...
};

So, when calling your template, you should use nullptr.

But, if you want to use NULL then you must type-cast it as (char*)NULL (or equivalent), or whatever other pointer type the parameter is expecting, eg:

awrap(handlepath, handle, path, (char*)NULL, 0, coll, (char*)NULL);

NULL is a macro which can either be defined as nullptr or as a zero-valued integer literal (e.g. 0 or 0L). Which one is implementation-defined, but because only the latter choice is valid in C and pre-C++11 the chances of seeing the latter are good.

nullptr is an object of nullptr_t. Any expression of this type is always a so-called null pointer constant, meaning that it can be implicitly converted to a null pointer value of any pointer type.

A zero-valued integer expression however is not always a null pointer constant. Specifically only null-valued integer literals are null pointer constants that can be converted to pointer types.

So, if you pass 0 directly to a function expecting a char* that works out fine, the literal 0 is a null pointer constant and can be converted to a the pointer type implicitly, resulting in a null pointer value.

But you are passing the literal on to awrap as integer type (by deduction). When you use the argument in func(args...) it is still an integer expression with value zero, but it is not an integer literal. Therefore the argument is not a null pointer constant and can’t be implicitly converted to char*.

So, you can’t pass 0 for a pointer parameter through the wrapper because you must name the literal exactly where the conversion should apply. And whether you can use NULL is implementation-defined. It works if NULL happens to be defined as nullptr, but not if it is a zero-valued integer literal.

That’s a good example why only nullptr should be used. The implicit conversion behavior of zero-valued integer literals exists only for historical reasons inherited from C. If the language was designed today, I doubt that anyone would add such a weird special case to conversions. Normally the possible conversions are determined by type and value category of expressions. This is the only special case where the value and the grammatical construction affect conversion behavior.