I'm opposed to including this at least until we've migrated to Rust. I'm also not convinced of the utility for complex use-cases (but can see the ergonomics win for trivial use-cases).

A few notes:

1. Usage of this is going to require quoting the task name in the shell.

~/repos/tests$ turbo eslint-*  
 ERROR  run failed: task `eslint-config-custom` not found in `scripts` in "package.json". Are you sure you added it?
Turbo error: task `eslint-config-custom` not found in `scripts` in "package.json". Are you sure you added it?
~/repos/tests$ ls -1 | grep eslint
eslint-config-custom
~/repos/test$ turbo foo*
zsh: no matches found: foo*

2. Task names right now are "just strings" and this creates a new microsyntax for them.
3. The special-casing of : is a non-starter for me. I get that * needs an implicit terminator to avoid arbitrary substring matching, but that's asking for trouble. turbo build:*:thing can match build:one:two:thing and that's okay. As a user you control task names and you can pattern to avoid this. We could also choose to enforce that task name glob matches /.*\*$/ to make it a suffix match.
4. Enabling the full globbing power of doublestar feels like far too much rope. We should reduce to just * (which would be equivalent to /.*/. If you need alternation to specify your task names something is wrong.
5. I generally feel like people just bundle their definition for this inside of package.json. People feel like this will get use, but you're likely over-specifying targets. Any non-leaf nodes specified by this are unnecessary.
6. You can always add a new single leaf node with each of the would-be-glob-targeted tasks.

This:

# Quotes required, don't forget!
turbo "lint:*"

Becomes:

{
  "pipeline": {
    "lint": {
      "dependsOn": ["lint:eslint", "lint:prettier"]
    }
  }
}

turbo lint

7. Paired with --filter there's no particular reason to namespace your tasks by package. Packages can already be targeted by glob using path:

turbo build --filter="{packages/*}"

8. Not adding this into dependsOn creates a distinction in how you address tasks in config and how you address tasks on CLI. That incongruity is unfortunate.

Given all of this I suspect that the value we're targeting here is semi-related tasks.