Not quite conflicting urls

[Quafadas]

I'm using smithy to generate a client which wraps a third party API. I'm getting this error;

[ERROR] ils.smithy.ilsop#GetAllSubmissionTags: Operation URI, `/submissions/v1/submissions/queries/unique-tags`, conflicts with other operation URIs in the same service: [`ils.smithy.ilsop#GetSubmission` (/submissions/v1/submissions/{id})] | HttpUriConflict C:\temp\Scala-ILS-Lib\smithyapi\smithy\Ilsop.submissions.smithy:38:1
[ERROR] ils.smithy.ilsop#GetSubmission: Operation URI, `/submissions/v1/submissions/{id}`, conflicts with other operation URIs in the same service: [`ils.smithy.ilsop#GetAllSubmissionTags` (/submissions/v1/submissions/queries/unique-tags)] | HttpUriConflict C:\temp\Scala-ILS-Lib\smithyapi\smithy\Ilsop.submissions.smithy:44:1

I get what it's complaining about, because it's possible, that one could submit an id, with value queries/unique-tags... although the definitions here are as follows;

@uuidFormat
string SubmissionId

structure SubmissionIdInput {
  @httpLabel
  @required
  id: SubmissionId
}

@readonly
@http(method: "GET", uri: "/submissions/v1/submissions/queries/unique-tags")
operation GetAllSubmissionTags {  
  output: Tags
}

@readonly
@http(method: "GET", uri: "/submissions/v1/submissions/{id}")
operation GetSubmission {
  input: SubmissionIdInput,
  output: ASubmission
}

I went and read the smithy spec which I think clearly states, that it views this as a conflict, even in the presence of the constraints above.
https://awslabs.github.io/smithy/2.0/spec/http-bindings.html#pattern-validation-and-conflict-avoidance

So this seems as per the design.

At which point then only thing I can think of doing, is spinning up a new service definition and client for one of the conflicting requests? Not super convenient, but workable - does that sound right?

[Baccata]

I'm afraid you've hit this bug : smithy-lang/smithy#1029, nothing Smithy4s can do about it.

At which point then only thing I can think of doing, is spinning up a new service definition and client for one of the conflicting requests? Not super convenient, but workable - does that sound right?

Yup, that's the workaround we're advising our users to do.

[Baccata]

AWS has assured us they'll be working on it, but AWS being AWS, there's no timeframe for a fix.

[Quafadas]

That's fine, thanks!