Yes, it was changed to OR so A<ctg> and <ctg>A (v4.2 section 5.4.2 Large Insertions) would return true.

It is true the check will now accept invalid alleles such as <ABC, but as noted elsewhere, it already accepts invalid alleles such as [ABC and downstream parsing and interpretation of the allele must be done by users of the API. The intent of this minimal pull is for a least-impact update to htsjdk so it doesn't choke on valid v4.2 allele. Should I raise a feature request for first-class treatment of symbolic alleles? I'm happy to write a proper implementation of SV allele handling (eg: htsjdk is also missing definitions for the 31 spec-defined SV headers).

The other problem I encountered is the VCF spec itself is unclear as to what a valid symbolic allele is. For example, AA<ctg> may or may not be valid so writing a unambiguously correct VCF symbolic allele parser is not actually possible at this point. I've raised this issue on samtools/hts-specs and the VCFTools-spec mailing list but I expect clarification will take some time.