I am inclined to call this WONTFIX.

Why do you want this?

We have added, for example,
   -Werror=missing-prototypes
to save us from getting and spending a lot of time on mysterious bug reports
that is the likely result of ignoring such a problem.

But the configure switch looks to not work as expected, --enable-compile-warnings=no and minimal ends passing the same flags, not what configure seems to suggest:
    case "$enable_compile_warnings" in
    no)
        warning_flags=
        ;;
    minimum)
        warning_flags="-Wall"
        ;;
    yes)
        warning_flags="$base_warn_flags $base_error_flags"
        ;;
    maximum|error)
        warning_flags="$base_warn_flags $base_error_flags"
        ;;
    *)
        as_fn_error $? "Unknown argument '$enable_compile_warnings' to --enable-compile-warnings" "$LINENO" 5
        ;;
    esac

    if test "$enable_compile_warnings" = "error" ; then
        warning_flags="$warning_flags -Werror"
    fi

With "minimal" I would expect it to only append -Wall... but looks to not work as intended :/

You're looking in the wrong place.  See configure.ac near line 261.
We add warnings beyond the set controlled by $enable_compile_warnings
It still boils down to this:

> Why do you want this?

Well, the idea is to prevent problems like this:
https://bugs.gentoo.org/show_bug.cgi?id=502178

That arise from time to time when, for example, people updates their gcc and, suddenly, the package that was compiling ok before, breaks now due -Werror usage. 

Also, probably https://bugs.gentoo.org/attachment.cgi?id=371096 will interest you :), but the problem I was trying to handle was the future breakages that could occur again in the future due -Werror usage :/

In this case you hit a macro not being defined.  Had you removed the
error flags you would have been able to compile, but not link.  So in
this case you wouldn't have benefited from avoid Werror.

But let's assume this had been about a function.  Without the Werror, you
could compile and also link.  In most cases, however, they wouldn't work.
Your package would compile, but I'm left with obscure errors happening
only on a users machine.  That's a nightmare to debug.

I really don't want to make it easy to end up in that situation; it's an
utter waste of everyone's time.  I like having the failure obvious like
here, but if you really don't like it, patch configure.ac and set
set_more_warnings to "no" instead.

Note, that the Werror usage here is very targeted to this situation
(as well as -Werror=format-security).  We do not add it for things that
do not matter.  As you discovered here, there is a bug that must be fixed.

As for the patch, I'll commit it.  It means that you are not up to date
with your libgsf, though.

In that case no problem. Thanks a lot for the explanation and sorry for the noise.

Regarding the real bug, not sure if I should open a new bug report forwarding that patch (well, you are aware of it already, then, I guess it's not needed). About libgsf version... maybe the user is running an old one, we are only requiring >=gnome-extra/libgsf-1.14.24 as it's the minimal version per configure, but we can raise it too of course

Best regards :)

Just seen your message in downstream report. All done then ;)