signal handling issues

Up to and including The Open Group Base Specifications Issue 6, the
following program was a correct way of using signal handlers:

----
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

static void alarmed(int unused)
{
    puts("I was alarmed!");
    alarm(2);
}

static void interrupted(int unused)
{
    puts("I was interrupted!");
    exit(0);
}

int main(void)
{
    struct sigaction sa;
    sigset_t omask;

    sigemptyset(&sa.sa_mask);
    sigaddset(&sa.sa_mask, SIGALRM);
    sigaddset(&sa.sa_mask, SIGINT);
    sa.sa_flags = 0;

    sigprocmask(SIG_BLOCK, &sa.sa_mask, &omask);

    sa.sa_handler = alarmed;
    sigaction(SIGALRM, &sa, NULL);

    sa.sa_handler = interrupted;
    sigaction(SIGINT, &sa, NULL);

    alarm(2);
    while (1) sigsuspend(&omask);

    return 0;
}
----

As the only requirement for functions not listed as async-signal-safe
was

In the presence of signals, all functions defined by this volume
of IEEE Std 1003.1-2001 shall behave as defined when called from
or interrupted by a signal-catching function, with a single
exception: when a signal interrupts an unsafe function and the
signal-catching function calls an unsafe function, the behavior
is undefined.

Since version 7, its behaviour is undefined because the following
requirement was added:

If the process is multi-threaded, or if the process is
single-threaded and a signal handler is executed other than as
the result of:
       

    The process calling abort(), raise(), kill(),
    pthread_kill(), or sigqueue() to generate a signal that is
    not blocked

    A pending signal being unblocked and being delivered before
    the call that unblocked it returns

the behavior is undefined if the signal handler
[...]
calls any function defined in this standard other than one of
the functions listed in the following table.

despite the statement from version 6 was retained as is. These two
requirements seem to contradict each other. It would also be
interesting to know what the point of this change was to begin with,
considering that it decreed that code whose behaviour had hitherto been
defined would now have undefined behaviour.

[I think this should be reported as a defect but there doesn't seem to
be a way to do that or at least no obvious way.]