`eval` pollutes the history when it runs "set -o history"

[_y]

Configuration Information:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe
-fstack-protector-strong -fno-plt
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc'
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS
-Wno-parentheses -Wno-format-security
uname output: Linux mycomputer 5.1.5-arch1-2-ARCH #1 SMP PREEMPT Mon May
27 03:37:39 UTC 2019 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.0
Patch Level: 7
Release Status: release

Description:
        When `eval` runs "set -o history", subsequent lines in the
        eval-ed string are recorded in the history.

        This breaks the following coding pattern:
                saved_options="$(set +o)" # save shell options
                ... # do some things with custom shell options
                eval "$saved_options" # restore shell options
        Indeed, if history is enabled (which is very likely), then the
        output of "set +o" will include the line "set -o history",
        followed by lines for enabling or disabling other options, and
        these following lines pollute the user’s history.

        What makes me think it is an actual bug is that when the
        "history" option was already enabled, "set -o history" should
        have no effect; yet lines before are not recorded, and lines
        after are recorded.

Repeat-By:
        $ env -i bash --norc --noprofile
        $ set -o | grep history
        history        on
        $ eval '
        > echo A         # this line is not recorded (expected behavior)
        > echo B         # neither is this one
        > set -o history # nor that one
        > echo C         # this line is recorded in the history
        > echo D         # this line is recorded in the history
        > '