In general, gRPC documentation is very clear because you're either in or out: if you have end-to-end HTTP/2 and trailer support, you're in and everything works. If you don't have both, you're all the way out and _nothing_ works. Connect aims for something more like progressive enhancement, where implementations support as much of the feature set as they can. Even if that's just unary (request/response) RPCs, it's still useful.
No matter what protocol you're using, bidirectional streaming requires:
1. A schema language with the concept of bidi streaming RPCs. If you're using Thrift, you're out of luck.
2. An HTTP/2 connection. If you're using Python and `requests`, you're out of luck.
If you have both of those, you're capable of bidi streaming. (gRPC's HTTP/2 protocol _also_ requires support for HTTP trailers.)
Protobuf supports bidi streaming RPCs. `connect-go` supports HTTP/2 (and trailers, for the gRPC protocol). So if you're using Protobuf schemas and a `connect-go` client and a `connect-go` server, you have full bidi streaming support and you can choose between any of the three supported protocols. If you're using a `grpc-go` client and a `connect-go` server, or vice versa, you have full bidi streaming support but only using the gRPC HTTP/2 protocol. The wire details differ between the gRPC, gRPC-Web, and Connect protocols, but the semantics are the same and all the Go APIs behave the same.
Hopefully that clarifies things. (If not, let me know and I'll take another run at it!)