From a CAA standards perspective, CAs have always been allowed to unilaterally make up parameters. That’s what they’re for.
An issuer MAY choose to specify issuer-parameters that further constrain the issue of certificates by that issuer, for example, specifying that certificates are to be subject to specific validation polices, billed to certain accounts, or issued under specific trust anchors.
The semantics of issuer-parameters are determined by the issuer alone.
DigiCert could create a ‘cats’ parameter so you could use ‘issue "digicert.com; cats=2"’ and require that 2 cats sleep on top of your CSR.
If a CA’s CAA parser crashes – or, worse, permits issuance improperly – in the face of parameters, it’s badly broken.
Because Let’s Encrypt implements the ACME standard, they’re following the ACME standardization process for the ACME CAA extensions. But that’s not really relevant to how CAs handle it.
Side note: I’m a bit worried by the hyphens in the parameter names, though. That could potentially cause problems. But parsers ought not to be that brittle.
I don’t know what that would do. I think it could plausibly be interpreted as allowing Let’s Encrypt to use any validation method. I don’t know how Let’s Encrypt will handle it.
I would think that the danger, if any, is that another CA altogether may not correctly parse the record in a multi-CA environment. If you literally wanted to restrict to Let’s Encrypt only and via DNS-01 only, I suspect the new form works perfectly for that. If you need to authorize multiple CAs, but only a particular validation method for Let’s Encrypt, I would make those changes and promptly test issuance at the entire set of authorized CAs.
If there’s a danger out there, it would probably be from another CAs’ software analyzing the CAA records, seeing something they didn’t expect (new parameters in the body of a CAA record with the issue tag), and failing secure (decline to issue).