I realised that Lame >V3.95 at "preset insane" has no padding-flag set.
Some decoders - like CEP - don't decode until the last frame, so some samples are missing.

Do you mean that they do not decode at all?

No... only the last few samples are missing.
But the filesize at 320kbps is also different, why?

e.g.
Isaac Hayes - Never Can Say Goodbye

filetype - playtime (decoded in CEP) - filesize
------------------------------------------------------------------------------
wav - 3:38.639 - 38.568.140 byte
Lame 3.93.1 @320 (insane) - 3:38.723 - 8.748.929 byte
Lame 3.96 @320 (insane) - 3:38.535 - 8.741.412 byte
Lame 3.93.1 @256 (ap cbr 256) - 3:38.723 - 6.999.143 byte
Lame 3.96 @256 (ap cbr 256) - 3:38.723 - 6.999.143 byte

encode string for CBR 320: --alt-preset insane
encode string for CBR 256: --alt-preset cbr 256

Used encoder:
Lame V3.93.1 from Mitiok's Site
Lame V3.96 from Mitiok's Site

Edit:
The decoded playtime in CEP is different, decoded with F2k all files are the same!
It seems this is a problem in CEP.

Because of padding. When it is used, some frames are one byte longer than those without padding, resulting in different file sizes in your case.

It looks like your decoder uses file size to calculate number of frames, then decodes only that many frames. Without padding, calculated number of frames will be lesser than actual number, so your decoder skips last few frames.

44kHz audio CBR mp3's should always use padding to avoid such problems.

are versions 3.96, 3.93 and 3.90.3 supposed to give exactly the same results in cbr mode (--api for instance)?

Regarding bitrate, yes.
The change here is because of the missing padding in 3.96. (already corrected in CVS)

Are there any quality restrictions for the files without padding?

btw, might be irrelevant to ask but has --api switch been improved in 3.96?

Very minor: 1 byte less in frames without padding.