In the original 5218, the basis came more or less from
http://src.illumos.org/source/xref/freebsd-head/sys/sys/_null.h
but also I used NetBSD current as a reference.

Given this intermediate structure of old defs, I propose to simply drop mention of Mr Moolenaar.

Since this file only defines NULL, I wonder if it is crucial to keep the _SYS_NULL_H biz 
keeping only the #ifndef NULL guard

I'll add in any event /* NULL */ to the #endif

When I did this, I judged that the file went through contortions to 'sort of' define NULL

but fmtmsg.c and all the other users of fmtmsg.h I checked which actually use 'NULL'

seem to include stdio.h so NULL is defined already in the compilation unit.
richard@omnis:/home/richard/src/illumos-gate/usr/src$ git grep -l fmtmsg\.h\> '*.[ch]*' |xargs grep -wl NULL 
cmd/devmgmt/cmds/devattr.c
cmd/devmgmt/cmds/devreserv.c
cmd/devmgmt/cmds/getdev.c
cmd/devmgmt/cmds/getdgrp.c
cmd/devmgmt/cmds/listdgrp.c
cmd/devmgmt/cmds/putdev.c
cmd/devmgmt/cmds/putdgrp.c
cmd/fmtmsg/main.c
cmd/logins/logins.c
cmd/setuname/setuname.c
cmd/users/users.c
lib/libc/port/gen/fmtmsg.c
richard@omnis:/home/richard/src/illumos-gate/usr/src$ git grep -l fmtmsg\.h\> '*.[ch]*' |xargs grep -lw NULL |xargs grep -l stdio\.h
cmd/devmgmt/cmds/devattr.c
cmd/devmgmt/cmds/devreserv.c
cmd/devmgmt/cmds/getdev.c
cmd/devmgmt/cmds/getdgrp.c
cmd/devmgmt/cmds/listdgrp.c
cmd/devmgmt/cmds/putdev.c
cmd/devmgmt/cmds/putdgrp.c
cmd/fmtmsg/main.c
cmd/logins/logins.c
cmd/setuname/setuname.c
cmd/users/users.c
lib/libc/port/gen/fmtmsg.c

To me, simplification imposed.
As to why these contorsions were taken, I presume no assumptions

were made as to whether the caller included stdio.h or unistd.h or something

defining NULL, therefore precaution was done to avoid polluting namespace.

That seems silly given that there is no guarantee that certain header won't pull in another header. (At least it is my understanding that it's implementation defined.)
Regardless, I'm keeping MM_NULLLBL as is if it will speed up getting this committed.

I guess I'm not sure I follow exactly.  Do you mean as it was?
As indicated above, from my research, all gate users of fmtmsg.h pull in 'NULL' from stdio.h
Myself, I saw absolutely zero added value to defining '_NULL', then 'NULL' sometimes, 

just to define specifically:
#define MM_NULL     0L

#define MM_NULLLBL  ((char *)_NULL)
#define MM_NULLSEV  MM_NOSEV
#define MM_NULLMC   MM_NULL
#define MM_NULLTXT  ((char *)_NULL)
#define MM_NULLACT  ((char *)_NULL)
#define MM_NULLTAG  ((char *)_NULL)

where _NULL could simply be replace by '0' already in this context.
BTW, perhaps I should mention that that manpage for fmtmsg.h indicates

    The table below indicates the null values and identifiers for

       fmtmsg(3C) arguments. The <fmtmsg.h> header defines the macros in the

       Identifier column, which expand to constant expressions that expand to

       expressions of the type indicated in the Type column:
'NULL', itself, is not in this list, so there is no contract specifying that 'NULL'

needs be defined in fmtmsg.h.
Finally, I just happended to notice as well that http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fmtmsg.h.html

shows that my proposed definition is more or less what is defined by POSIX (abeit with extra parentheses that

I guess I could to toss if need be).

Oh! I didn't realize that MM_NULL* were part of the interface.  I saw that you filed #6563.

pdir is an unsigned char here, it feels awkward assigning '\0' to what is unsigned.

Later on, the 'c' variable is a normal signed char.
I'll swallow and make these all '\0' as you indicate.

I guess 'regress' is relative... The whole point of 5218 is to centralise the NULL definition to something

more 'better'(?)... but in the short run, this first stage is simply centralisation not the final solution.

Agreed - while it's a "regression" as far as the type is concerned, this centralization is the first step to making NULL definition modern everywhere.

Given that we're wsdiffing relatively cleanly, I'm not terribly worried about this anymore.

I haven't noticed any "fallout", if that is the question. I have not run wsdiff

Given that we're wsdiffing relatively cleanly, I'm not terribly worried about this anymore.

I was going to say 'unistd.h, already included in this same file'

Thanks for pointing this one out, which is in a totally different set of includes.
I notice all of ucbcmd use stdio.h in ucbhead which does defines NULL, but in ucblib

there is getwd.c that uses NULL but only references unistd.h which would normally have

NULL defined, but in ucbhead doesn't.
If there is no opposition, I simply added sys/null.h to ucbhead/unistd.h and corrected

the NULL definitions by including instead sys/null.h in ucbhead/stdio.h and ucbhead/dbm.h

Weird...I think rb messed up a bit.   LGTM.