Please tell if there is any option to get around this?
If you want your signatures to be interoperable, there is no way around that.
I readed this article and understood, that each previous digital signature (even detached) is included into SignedContent of the next signature
That answer still represents the current situation. If anything, it has been confirmed by newer specifications, e.g. the PAdES specifications referenced in that answer merely were 'technical specifications' (ETSI TS 102 778) and there now are actual norms (ETSI EN 319 142) which also require a pdf signature to sign everything in its revision except its own signature container. Also ISO 32000-2 has been published, still having that requirement for its interoperable signatures and additionally including a shortened copy of the PAdES specification.
You stress "even detached" here. The "detached" in the context at hand only refers to the structure of the CMS container which is embedded in the PDF; it in particular does not refer to the signature being more separated from the PDF or anything like that.
If you don't need to be interoperable, though, there are some options, here two of them which still are quite near to the interoperable signatures:
You can ignore the requirement that a pdf signature must sign everything in its revision except its own signature container.
For example you can prepare multiple signature fields and dictionaries in a single new revision of the document and set each signature's signed byte range to exclude the placeholders of all these signatures.
you can ignore the requirement that there is only a single SignerInfo in the CMS signature container and put SignerInfos from different signing parties into a single signature container in a single signature field.
Common PDF signature validators will,
in case of signatures created as described in the former option, not positively validate, at least most of them,
either because their code is programmed for only two ranges of signed bytes (i.e. a single gap) and so only uses the first two ranges resulting in a wrong document hash;
or because they explicitly require that a signature covers its whole revision minus the single placeholder for the signature container of the signature field being validated; the number of validators of this kind surely has risen since the publication of the "Security of PDF Signatures" master thesis by Karsten Meyer zu Selhausen at the Ruhr-Universität Bochum, see this question.
in case of signatures created as described in the latter option, appear to positively validate, at least many of them, until you look at the validation result in detail and realize that they have validated only one of the SignerInfos and ignored the others.
For example in case of two SignerInfos Adobe Reader validates the second one (I assume it always validates the last one) and eSig DSS validates the first one, and neither one of them currently indicates in the validation result that there may be another SignerInfo present.
A large Swedish security company, for example, implements the second option in its software; in its home brew format PDF/CAdES-A it inserts CAdES-A containers as CMS container in PDFs and allows multiple SignerInfos therein. Obviously, therefore, its own software will recognize and validate all SignerInfos. Nonetheless, this is a home brew solution and not interoperable.
