No, I don't plan to add a -printf format for mime/magic.
The output doesn't sort in well in the other output formats anyway,
because it's quite verbose.

If I would think about adding such a format, I'd go starting to make
use of the "%{...}" syntax which is currently reserved for future; hence
a "%{magic}" and "%{mime}" would fit - not sure about rawhide, though.

Re. magic/mime implementation:

First of all, it's the first time find looks at file content, and
that processing (open/read/lookup/close) is by magnitudes slower than
the other tests in find(1).

Having played with it for some time now, I have major qualms to
add libmagic support:

a) file(1) has some more options than the -i (for mime output) option.
Of course, they're all available via flags in libmagic.
But it would be strange to have to add further flags or knobs
in find(1) to support these options as well.
But people will require it - "just that one little thing".
That are discussions we have to avoid.

b) error handling:
While libmagic has the flag MAGIC_ERROR to indicate an error
via return value NULL instead of placing the error string
into the magic result buffer, that does not work for
all cases, e.g. the simple open/EPERM case: we still get the error
message "regular file; no read permission" as magic string
instead of NULL.
Likewise file(1):

$ file -E /etc/sudoers; echo $?
/etc/sudoers: regular file, no read permission
0

I looked into file/libmagic code, and found various such places.
Also the library function magic_error does not indicate
an unreadable file as error.
We'd have to single out every such error by string matching,
which I'm not willing to do.  Proper error handling seems to
be tough with libmagic.  I'm not sure how and which other
projects are using libmagic, but the current state of error
handling doesn't work for how find(1) would need it.

c)
It's not really find's business to look at the content of files,
and there are already ways to do the filtering with file(1) as shown
below (*): searching for magic strings or mime types can already be
done "the UNIX way" (i.e., one tool for one purpose).

Even if one likes to continue after the "magic check" with post-processing
via the find(1) command again, it is safe with the -files0-from option
for any kind of exotic file names incl. control or newline chars:

$ find -type f -size -40000c -mtime -10 -exec file -00 '{}' + \
    | sed -nz 'h;n;/^C source/{g;p}' \
    | find -files0-from - -printf "* %p\n  size: %s\n  inode: %i\n"
* ./find/defs.h
  size: 19707
  inode: 216534
* ./find/util.c
  size: 29571
  inode: 217027
* ./find/pred.c
  size: 37310
  inode: 152256

Obviously, that would be much easier if file(1) would provide options
to filter by certain magic/mime strings (as it does to exclude some tests).

I was quite enthusiastic about adding libmagic in the beginning,
but with the issues described above - above all the problematic error
handling -, I'm afraid I can't add libmagic support now.
I'm inclined to abandon or throw away my local work.

(*) The other day, maybe another one comes up with the idea that there's
a little library to get the content of cell A1 of a spreadsheet file,
or the title of a PDF file.  I don't believe it's a good idea to link
all those libraries, but instead encourage people to write tools which
fit well into UNIX pipes and transport remaining file names with
safe and Zero-terminated strings.