Does the Bluetooth protocol inherently support bidirectional data transfer?
I think the specific answer to your question lies in the history of the Bluetooth protocol. Here's what I found:

Bluetooth was created in 1994, and is used to exchange data over short distances. The protocol is managed by Bluetooth Special Interest Group. IEEE standardized it as 802.15.1, but they no longer maintain it. So your answers lie with the Bluetooth SIG.

BISG is made up of over 30,000 Tech and TCOM companies, and a network of patents. To find the original uses of bluetooth, I'd use google's patent search and take a look at some old tech.


Here's a patent from 2001, using Bluetooth to modify network IP:
That article mentions first establishing a bluetooth connection, then both sending and receiving data/indicators from the connected device.

Furthermore, if you look at the Bluetooth Core Spec, you can see it mentions:


While each implementation has specific requirements that are detailed in the Bluetooth specification, the Bluetooth core system architecture has many consistent elements. The system includes an RF transceiver, baseband and protocol stacks that enable devices to connect and exchange a variety of classes of data.

Since the core spec maintains consistent design, and that design includes a transceiver, it leads me to believe Bluetooth was always designed to both send and receive.
----- UPDATE -----
Two-way comm is called a Full-duplex transmission. It means data can be transmitted in both directions on a signal carrier at the same time.
Here is the Bluetooth 1.0 spec, released in 1999. It's the first official release of Bluetooth.

Bluetooth is a short-range radio link intended to replace the cable(s) connecting portable and/or fixed electronic devices. Key features are robustness, low complexity, low power, and low cost.
Bluetooth operates in the unlicensed ISM band at 2.4 GHz. A frequency hop transceiver is applied to combat interference and fading. A shaped, binary FM modulation is applied to minimize transceiver complexity. The symbol rate is 1 Ms/s. A slotted channel is applied with a nominal slot length of
625 µs. For full duplex transmission, a Time-Division Duplex (TDD) scheme is used. On the channel, information is exchanged through packets. Each packet is transmitted on a different hop frequency. A packet nominally covers a single slot, but can be extended to cover up to five slots.

In its first official release, Bluetooth supported FDT.
Digger further (pg42) - a piconet (2 or more connected BT devices) follows the master-slave protocol. Only a single device can be the master of the piconet, which broadcasts out to the slaves. Only the master can be active in that channel, but slaves are allowed to respond to the master device. So devices can ping and expect a response.
I forget where I read (think Flow Control section), but they mentioned that implementation is key and Bluetooth is pretty much agnostic of the flow control between devices. It is just generally a better implementation to broadcast from one end of the devices because synchronous packets may need to buffer between endpoints (thus getting corrupted).
So while most implementation of bluetooth is one-way in practice (speaker, headphones, etc) - Bluetooth technology was built to support both flows of communication.