Between changes made in 5.16, safe signals, perlIO and buffering, an occasional duplication of some DESTROY printed messages isn't something I'd worry about .... unless it happens with perl-5.16.3 :)

This is not mere duplication of a printed message. As mentioned, when you enable the Devel::Peek statement you can see it's different references being provided in each call. Also this whole problem originated from a much more elaborate test-case where the result was that an XS module called free() twice on the same pointer in the same process. To my knowledge, this can't be explained with filehandles and buffers.

Also, there is always the possibility that while first Ctrl+C is being cached, and first server is being destroyed, another server is forked ...

Yeah... but strange that that new server get's the same PID as one of the old processes then.

I'd try only creating variables inside sub process_request as Net::Server::PreFork documents :)

I can't find that documented... anyway, that would of course be wise if the variable was a per-request variable. But this whole problem originated from needing to initialize a server global peace of data for all workers to be able to read.

And PS: ... The title hinted at the possibility that there was some documented caveat wrt. global destruction phase in certain Perl versions which I hadn't found. ... btw...this seems to happen only during global destruction

This is not mere duplication of a printed message. As mentioned, when you enable the Devel::Peek statement you can see it's different references being provided in each call.

Can you add  STDOUT->autoflush(1); and show that output ?

Missing autoflushing may (as discussed else in this thread) explain why the "END DESTROY" line is not always printed. It doesn't explain the blow output of 2 different references being given to 2 calls to DESTROY in the same process though:

^C======= BEGIN DESTROY:11632========
2014/05/19-10:36:43 Server closing!
SV = IV(0x11ba5d8) at 0x11ba5e8
  REFCNT = 1
  FLAGS = (ROK,READONLY)
  RV = 0xe462b8
  SV = PVHV(0xcf8880) at 0xe462b8
    REFCNT = 1
    FLAGS = (OBJECT,SHAREKEYS)
    STASH = 0xd10d40    "MyModule"
    ARRAY = 0x0
    KEYS = 0
    FILL = 0
    MAX = 7
    RITER = -1
    EITER = 0x0
======= BEGIN DESTROY:11632========
SV = IV(0x11ba4d0) at 0x11ba4e0
  REFCNT = 1
  FLAGS = (ROK,READONLY)
  RV = 0xe462b8
  SV = PVHV(0xcf8880) at 0xe462b8
    REFCNT = 1
    FLAGS = (OBJECT,OOK,SHAREKEYS)
    STASH = 0xd10d40    "MyModule"
    ARRAY = 0xfa0e30
    KEYS = 0
    FILL = 0
    MAX = 7
    RITER = -1
    EITER = 0x0
============ END DESTROY:11632========
======= BEGIN DESTROY:11631========
SV = IV(0xd103a0) at 0xd103b0
  REFCNT = 1
  FLAGS = (ROK,READONLY)
  RV = 0xe462b8
  SV = PVHV(0xcf8880) at 0xe462b8
    REFCNT = 1
    FLAGS = (OBJECT,SHAREKEYS)
    STASH = 0xd10d40    "MyModule"
    ARRAY = 0x0
    KEYS = 0
    FILL = 0
    MAX = 7
    RITER = -1
    EITER = 0x0
============ END DESTROY:11631========
[download]

The actual Perl object is also slightly changed... in a way I don't find meaningful... but then... I don't know the perlguts that well. I would primarily suspect a memory corruption reason for trashing the data. But it would be strange if such a problem never gave other symptoms with Net::Server::Prefork.