I'm shocked this hasn't come up before, but yeah this is a pretty big bug in Bundle field ordering. The order of fields in a Bundle is defined by the order the actual objects representing the fields were constructed (which in most cases matches Bundle field order, but as shown in the issue, may not). Using the order fields were constructed is legacy behavior from before we really had a way to determine field order. We can determine field order now in the compiler plugin so we can fix this.

Here is an example using the latest release (6.4.0) showing the issue (and how by-name generator parameters interact with it):

//> using scala "2.13.12"
//> using dep "org.chipsalliance::chisel:6.4.0"
//> using plugin "org.chipsalliance:::chisel-plugin:6.4.0"
//> using options "-unchecked", "-deprecation", "-language:reflectiveCalls", "-feature", "-Xcheckinit", "-Xfatal-warnings", "-Ywarn-dead-code", "-Ywarn-unused", "-Ymacro-annotations"

import chisel3._
// _root_ disambiguates from package chisel3.util.circt if user imports chisel3.util._
import _root_.circt.stage.ChiselStage

class Bundle1(gen: => UInt) extends Bundle {
  val a = UInt(8.W)
  val b = gen
  val c = UInt(8.W)
}
class Bundle2(gen: UInt) extends Bundle {
  val a = UInt(8.W)
  val b = gen
  val c = UInt(8.W)
}

class Foo extends Module {
  val in0 = IO(Input(new Bundle1(UInt(8.W))))
  val in1 = IO(Input(new Bundle2(UInt(8.W))))
  val out0 = IO(Output(UInt(24.W)))
  val out1 = IO(Output(UInt(24.W)))

  out0 := in0.asUInt
  out1 := in1.asUInt
}

object Main extends App {
  println(
    ChiselStage.emitSystemVerilog(
      gen = new Foo,
      firtoolOpts = Array("-disable-all-randomization", "-strip-debug-info")
    )
  )
}

This gives:

// Generated by CIRCT firtool-1.62.0
module Foo(
  input         clock,
                reset,
  input  [7:0]  in0_a,
                in0_b,
                in0_c,
                in1_b,
                in1_a,
                in1_c,
  output [23:0] out0,
                out1
);

  assign out0 = {in0_a, in0_b, in0_c};
  assign out1 = {in1_b, in1_a, in1_c};
endmodule

Fixing this involves:

1. Ensuring the order coming out of the compiler plugin is correct (including with inheritance and virtual methods)
2. Getting rid of the sorting by _id here.
3. Providing some migration path since fixing this is a silent change to behavior. Yes it's a bug fix but users may accidentally rely on the current order so we need a way to ensure their code doesn't silently break. Easiest option is probably to add a migration flag that emulates the old behavior (a la Change the width of static shift right #3824) so that users can generate Verilog with and without the flag and diff or LEC the result to see if their are any issues.

what is the "right order" here? follow up, what's the right order for the bundle elements a and b in something like

case class GenericBundle[T <: Data, U <: Data](val a: T, val b: U) extends Bundle
val in1 = IO(Input(GenericBundle(a = Bool(), b = UInt(8.W))))
val in2 = IO(Input(GenericBundle(b = UInt(8.W), a = Bool())))

The right order is the order of the fields in the definition of the Bundle, so for your GenericBundle it should always be a then b no matter how it's instantiated with named parameters.