TLS re-negotiation vs resumption
Re-negotiation may happen in the middle of existing session, "session
  ticked" or "session Id" are not required to find "current state
  parameters", just 5 tuple may be used to look for proper running
  session context.


Yes.


  [...]BUT ClientHello message itself is encrypted. How this is solved for
  TLS1.2 ?


The ClientHello on an abbreviated handshake is in fact not encrypted. The message flow for an abbreviated handshake goes roughly as follows: Client sends unencrypted ClientHello, Server responds with ServerHello, ChangeCipherSpec and Finished message and client answers with ChangeCipherSpec and Finished message and application data. Also see page 37 of RFC 5246.


  in both cases client-server dialog follow abbreviated Handshake


No, only for session resumption the abbreviated handshake is used, for renegotiation a full handshake is performed.


  In opposite resumption may happen even after actual connection has
  been closed


Yes.


  In context of TLS1.3 renegotiation is done now using KeyUpdate message
  and clearly described by draft, but resumption has the same issues.
  How resumption is solved for TLS1.3 ?


Section 2.2 of the TLS 1.3 draft (-23) talks about the session resumption protocol flow. Section 4.6.1 talks about how the ticket mechanism works in detail. Section 4.2.11 talks about how the tickets are used in the Hello Messages. It turns out that the client may offer the server multiple PSK identities in the (cleartext!) ClientHello of which the server selects and thus "consumes" at most one and indicates which in its ServerHello message.