Try using the following config:

- job_name: myJob
    metrics_path: /probe
    static_configs:
      - targets: [ tld , tle, tlf ]
        labels:
           host: host1:8112
      - targets: [ tod , toe, tof ]
        labels:
           host: host2:8112

    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        source_labels: [host]

It puts the label host into the label __address__, so Prometheus or vmagent scrapes the address defined in the host label per each static_config.

See more details about __address__ pseudo-label in these docs.

Incorrect understanding

I think there was a mistake in my understanding of how labeling in prometheus works. My incorrect understanding was:

1. before applying regex, string would be first split on separator (otherwise what is its purpose?),
2. each substring has regex evaluated against it,
3. if match groups are declared and found, they will be available as indexed values available to use in target_label and replacement fields.
4. if regex does not match, then that substring will be ignored.
5. because regex is expected to be applied to each substring after the split, it will lead to multiple labels from multiple substrings.

Correct understanding

However, from brian-brazil's post linked in his answer and Prometheus's documentation, it seems the following happening:

1. All __meta tags are combined into one long separator separated line.
2. regex is applied on that line only once.
3. If regex matches and includes groups, they are indexed beginning from 1 and available for use in target_label and replacement.
4. separator seems to be getting ignored in this section even if you mention it.

Config from corrected understanding

From this idea and following from example in the question, I was able to make the following config that works

relabel_configs:
- source_labels: [__meta_consul_tags]
  regex:         '.*,a=([a-z0-9_]+),.+'
  target_label:  'a'
  replacement:   ${1}

- source_labels: [__meta_consul_tags]
  regex:         '.*,b=([a-z0-9_]+),.+'
  target_label:  'b'
  replacement:   ${1}

- source_labels: [__meta_consul_tags]
  regex:         '.*,c=([a-z0-9_]+),.+'
  target_label:  'c'
  replacement:   ${1}

- source_labels: [__meta_consul_tags]
  regex:         '.*,d=([a-z0-9_]+),.+'
  target_label:  'd'
  replacement:   ${1}

Caveats

I believe both approaches (the approach brian-brazil wrote in his blogpost, and what I am using above) have caveats - we either need to know all the labels we want beforehand, or have a set number of them. This means if a developer wants to associate different, or more labels with his/her service, s/he would need to work with ops as general flow will not be able to handle it. I think it is a minor caveat that should be addressed.