Good news, this is already fixed. A Databricks maintainer confirmed the bug on your GitHub issue and shipped databricks-openai==0.16.0 together with databricks-ai-bridge==0.20.0 on June 10 to resolve it. So the actual fix, instead of pinning databricks-vectorsearch<0.74, is just to upgrade:

python -m pip install -U "databricks-openai>=0.16.0"

That pulls in the compatible databricks-ai-bridge version and the import works normally again.

On your other questions:

databricks/databricks-ai-bridge is the right place to file issues, it's the source repo that publishes databricks-openai, and it clearly is actively monitored, your issue went from filed to root-caused to a released fix in four days.

For databricks-vectorsearch and databricks-ai-search, they come from the same repo. The short version of why this broke: Vector Search was renamed to AI Search, databricks-ai-search is the new canonical package, and databricks-vectorsearch is now kept around as a thin compatibility shim that re-exports from databricks-ai-search with a deprecation warning. That rename and shuffle is almost certainly what shifted the symbol databricks_openai's retriever tool was importing.

On using the plain openai client instead, that's a legitimate and fully documented path if all you need is chat completions against a serving endpoint. Point the OpenAI client at <your-workspace-url>/serving-endpoints as the base URL and use a Databricks PAT as the API key, no databricks-openai package required. You'd only need databricks-openai specifically for the extra convenience wrappers, like the Unity Catalog function toolkit or the vector search retriever tool integration, that the plain client doesn't give you.