One way I can think of that will solve this problem is to do something like:

    resource "aws_instance" "nomadclients" {
      ami = "${count.index > 2 ? data.aws_ami.nomadclient_tick.image_id : data.aws_ami.nomadclient_tock.image_id}"
      instance_type = "t2.micro"

      count = 6

      iam_instance_profile   = "${aws_iam_instance_profile.consul-join.name}"
      subnet_id              = "${element(aws_subnet.consul.*.id, count.index)}"

      vpc_security_group_ids = [
        "${aws_security_group.rule01.id}",
        "${aws_security_group.rule02.id}",
        "${aws_security_group.rule03.id}",
        "${aws_security_group.rule04.id}",
      ]
    }

The downside to this approach (in TF < 0.12), however, will become apparent when you want to modify the number of instances in one or both pools. This arrises from the way hcl v1 manages the counter index with each resource in the state; That is each resource is linked to a specific index and when that index is altered in someway, terraform will attempt to adjust the resources at each respective index accordingly.

Because of these headaches, we decided to abandon hcl for these use cases and ended up writing our own preprocessor that takes a JSON configuration and generates individual JSON-based HCL (ie. .json.tf) that terraform can then use. We can leverage proper templating to generate many variants of a single resource in a higher level language, while still using terraform to manage the infrastructure and it only adds one additional step to the plan + apply process.