There are no "hacks", no special hoops to jump through to make Opus play gapless, in the sense that there is no silence between one track and the next.  The way that it is encoded means that tracks can play back continuously without any tags or special processing.  libopusfile is a library that does this (more or less) automatically. Programs that don't use libopusfile are a little more complex to write and apparently some of them did not play back tracks gaplessly, but that could be considered a bug of the player.

The lossy processing that Opus uses means that the value of an encoded sample can depend on the value of several previous samples.  This does not automatically happen at the start of a track, so that there is potentially a small glitch in the audio between the last sample of one track and the first sample of the next.  This is not a gap as such and it isn't usually audible, or at least not noticeable.  The examples where it is audible are not exactly typical music.  This isn't an issue which is unique to Opus, but its LPC and built-in resampling mean it can be much more significant in Opus.  I went through half a dozen gapless albums tonight and couldn't spot any glitches.

libopusenc is a relatively new library for encoding that includes functions to encode the start of one track relative to the end of the previous track so that there is no such glitch.   To do that special processing it must be aware that the two tracks are "continuous", so the input tracks cannot be handled as separate files.  opusenc in opus-tools 0.2 uses libopusenc, but only processes individual files so not much help.  I'm not sure that there any issues left when the tracks are encoded using the correct LPC extension code from libopusenc, but that's a moot point if there are no encoders doing it.  Maybe I'm missing something?

The Opus Tools already encode the first frame by priming both the resampler (if used) and part of the first frame itself with linear predictor output going backwards from the input samples. Technically, it should also be padding the end of the file with such.

Vorbis already does this transparently in the libvorbisenc library, and handles decoding and cutting out the priming samples in the libvorbisfile decoding library.

Opus does it in the encoder tool, and any best effort decoder which handles the delay field and truncates the end of the stream by the granule position values, should already handle this automatically. libopusfile, while it came late, just makes this easier and transparent to the application using it.

the graphic that you show doesn't exactly map my experience in that other thread, because your graphic shows the cut in the middle of the ressonating change (that small sinus added), while in my case the ressonation was entirely on the beginning of the second sample.

@Case : Although I assume that you made an exact 20 seconds snippet so that the 480000 sample should be the exact half, the graphic that you show doesn't exactly map my experience in that other thread, because your graphic shows the cut in the middle of the ressonating change (that small sinus added), while in my case the ressonation was entirely on the beginning of the second sample.
Can you verify your test?