Thanks for walking through a use case in detail. As I understand it, Topics could definitely be used to gather some general interests of people known to be customers of a certain type, and then to target ads on other sites to a lookalike type audience of people who have those same interests (as inferred from browsing history), without ever tracking an individual user who visited your site and directly target them in another context.

I don't know how effective that advertising would be compared to the existing flow -- presumably the framing of the ads would need to be different since you're reaching mostly new visitors rather than existing customers that you think are interested in a particular purchase -- but it seems feasible. As a privacy matter, I don't know if users expect that their interests are going to be collected over time by the shop in order to construct this targeting strategy, but your use case would primarily make use of aggregated data.

(Chrome's current design for Topics would require that a widely-used third-party be embedded to determine the topics assigned to the existing visitors, beyond the topic category of the online shop itself. That design feature is an open question, but under the current design it's likely that some vendors would provide that service.)

That wouldn't be the same functionality as your current flow, which is more like re-targeting or a selected audience. There are some proposals to try to more closely replace that functionality with some different privacy properties (e.g. FLEDGE or PARAKEET).

Thank you @npdoty for your comments and a confirmation that my imaginary case looks reasonable ;)
I was worried that the approach might not work due to the following section in the explainer

Not every API caller will receive a topic. Only callers that observed the user visit a site about the topic in question within the past three weeks can receive the topic. If the caller (specifically the site of the calling context) did not call the API in the past for that user on a site about that topic, then the topic will not be included in the array returned by the API. The exception to this filtering is the 5% random topic, that topic will not be filtered.

Frankly speaking, I do not understand that statement, that is why I decided to describe the use case. I'm glad that you see no issues with that.

P.S. I know about FLEDGE or PARAKEET and how "interest groups" could be used theoretically.

That was the reason that I included this caveat:

(Chrome's current design for Topics would require that a widely-used third-party be embedded to determine the topics assigned to the existing visitors, beyond the topic category of the online shop itself. That design feature is an open question, but under the current design it's likely that some vendors would provide that service.)

Under the current Chrome implementation, if the shopping site itself directly calls browsingTopics(), it wouldn't get access to a range of topics based on the user's browsing on other sites, because of the proposed "witnessing" limitation. Perhaps that design limitation should be changed, although the reasoning was to limit the privacy implications of sites learning new information about the user. But even with that limitation, it could be that a widely embedded third party could be embedded on the shopping site page and have an agreement to pass on the topics that it sees about the user back to the shopping site itself.

@npdoty, I agree with your statement about the possible workaround

But even with that limitation, it could be that a widely embedded third party could be embedded on the shopping site page and have an agreement to pass on the topics that it sees about the user back to the shopping site itself.

Do we really want to make the shopper site owners' life miserable? 😩