If you've selected an OEM raster font in the console properties instead of a TrueType font (Consolas, Lucida Console, etc), then the console implements some magic to support the OEM character mapping in the raster font. The following shows that encoding to codepage 850 (the system OEM codepage in the UK and Canada) maps the characters that you've flagged, and only those characters, to an ASCII bell (0x07):

    >>> [hex(x) for x in range(0xFFFF)
    ...   if codecs.code_page_encode(850, chr(x), 'replace')[0] == b'\x07']
    ['0x7', '0x2022', '0x2024', '0x2219']

Please confirm whether you're using an OEM raster font. If you are, then this issue can be closed.

---

> UnicodeEncodeError: 'charmap' codec can't encode character 
> '\u2023' in position 0: character maps to <undefined>

Windows Python defaults to using the process active codepage (WinAPI GetACP) for non-console I/O. In Windows 7, the process active codepage is limited to the system ANSI encoding, which is limited to a legacy codepage such as 1252. You can force standard I/O to use UTF-8 via PYTHONIOENCODING, or force all I/O to default to UTF-8 by enabling UTF-8 mode via PYTHONUTF8.

---

For future reference, a console session is hosted by conhost.exe. The cmd.exe shell is a console client application, which uses standard I/O just like python.exe. If you run python.exe from Explorer, you won't see cmd.exe as a parent or in any way involved with the console session.

The confusion stems from how the system pretends that the process that allocates a console session owns the console window. This is a convenience to allow easily identifying and closing a console session in Task Manager, or via taskkill.exe. But it also leads people to confuse the console with the shell that they run -- such as CMD or PowerShell.