Bug 1279406

I have never seen that.  Although I re-run GDB together with inferiors, I never reload inferiors in GDB.

When that happens check at least:
(gdb) disable pretty-printer 
129 printers disabled
0 of 129 printers enabled
(gdb) info pretty-printer 
global pretty-printers:
  builtin [disabled]
    mpx_bound128
  objfile /lib64/libstdc++.so.6 pretty-printers:
  libstdc++-v6 [disabled]
[...]
(gdb) enable pretty-printer 
129 printers enabled
129 of 129 printers enabled
(gdb) info pretty-printer 
global pretty-printers:
  builtin
    mpx_bound128
  objfile /lib64/libstdc++.so.6 pretty-printers:
  libstdc++-v6
[...]

Created attachment 1095529 [details]
GDB log with comments showcasing the behaviour

You may have stumbled onto something. Even if it does not explain yet the reason for which this behaviour occurs.

Apparently my pretty-printers disappear somewhere along the road...

I'm providing a GDB log as an attachment where you can see the behaviour occurring (with some commments by myself) and the different outputs for the pretty-printer commands at separate points of execution.

I have it reproducible now although I do not know the reason yet:

echo -e '#include <vector>\nint main(){std::vector<int> l;\nreturn 0;}'|g++ -g -Wall -x c++ -;gdb -q ./a.out -batch -ex 'b 3' -ex r -ex 'p l' -ex r -ex 'p l' 
[...]
$1 = std::vector of length 0, capacity 0
[...]
$2 = {<std::_Vector_base<int, std::allocator<int> >> = {_M_impl = {<std::allocator<int>> = {<__gnu_cxx::new_allocator<int>> = {<No data fields>}, <No data fields>}, _M_start = 0x0, _M_finish = 0x0, _M_end_of_storage = 0x0}}, <No data fields>}

That's great news!

I never actually managed to get such a short example (hadn't thought of going THAT short...) where it occurs but I confirm that your command exhibits the same behaviour on my side. If I can be of any help just ask.

Some further info :
The example for which I gave the GDB log is actually reproducible (that's not always been the case on other occurrences) so I've been playing around a little bit. By trying different orderings of breakpoint, run and other commands I've become quite confident that the problems occurs at the second 'run' command: I was able to set a breakpoint before running and on the first run I was still able to pretty-print STL objects.

[patch] Python Pretty Printers get disabled on libstdc++ reload by GDB (PR libstdc++/68448)
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02418.html

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.