Considering this would be the 4th time that the hashed-string-length has changed, if you prefer not to change how the key parameter is hashed, and just document the limit in /help, I'd rather have the suggested 'k' switch that allows inputting the key/iv as hex strings, and we can hash our own key and IV without using MD5.

When $encode generates a hashed key due to using 'c' without the 'l' switch, it is hashing only the first 612 bytes of the key parameter. This behavior appears to have changed over the versions, related to prior related fixes, and affects both the RandomIV and Salted__ hashing methods at the same length. This does not affect ECB mode, where the 'l' switch determines whether the key parameter is limited to 56 or 72. So this should only affect users who are hashing very long strings into being their key, in an attempt to offset the usage of MD5.

Through v7.51 the same syntax hashed only the first 256 bytes of the Key Parameter. Then in v7.52 as a side-effect of fixing how literal keys longer than 56 were handled, only the first 56 bytes of the key parameter were hashed. Then, when the limit of hashing only the first 56 bytes was fixed, it changed to the current behavior of hashing only the first 612 bytes.

This next example demonstrates using a fixed Parm4 string, where increasing the length of the key parameter ceases to change the key at lengths exceeding 612. And forum readers should not be worried about all strings in the column having the same beginning, since that's where the header is.
Code
alias blowfish612 {
  var %i $iif($version <= 7.51,246,$iif($version < 7.56,46,602)) , %j 1, %string $str(abcdefghij,400) , %prev
  while (%j isnum 1-20) {
    var %key $left(%string,%i)
    var %line $encode(Message,mcir,%key,Fixed_IV) $&
      $encode(Message,mcs,%key,SameSalt)
    echo $iif(%line === %prev,4) -ag %i : %line
    var %prev %line | inc %i | inc %j
  }
}