+    %#lp[x]		0123456789abcdef[rwxRWE,0000000000000000,ffffffffffffffff]

Space before "[", and "-" between the bounds instead of "," to match the
format below.

Additionally, to match [1], all values should be preceded by "0x".

So that would actually contradict to how pointers/addresses are being currently
printed where the '0x' prefix is not added unless explicitly requested. But then
the '#' flag used for that purpose is already being overloaded to switch to
simplified format. Note also that [1] does mention being compliant with existing
formats. I could use the prefix for the simplified format only, but that one can
cause some confusion. No strong opinion here.

AFAICT there is no significant divergence in printk() w.r.t. 0x: just like
in standard printf(), you don't get 0x unless you ask for the "alternate
format" with the # flag. You could certainly argue with the choice of using
the # flag to ask for the simplified format too, but since we're using that
too I'd just go for the same format as [1]. I might be missing something
about how printk() handles things though.

In theory the '#' flag for "%p" format is undefined result (and that's for
printf which will trigger a warning on that one:
	warning: '#' flag used with ‘%p’ gnu_printf format [-Wformat=]
). Kernel's printk will allow that but that's probably not really intended.
Plain pointers (with plain "%p") are being printed without the prefix.
Now with capability printing, the '#' flags gets somehow legitimate, so I guess
for this particular case we could play along with [1] and add the prefix for
simplified format. Which might actually make sense while looking at other 
printk extensions to '%p' format.