I am not familiar with bluetooth networking, so I may be off in
understanding what you are trying to do.

The question of tap(4) vs tun(4), and how many devices is really about
how the bluetooth protocol works.  I suspect that none of these are
entirely appropriate.  So I have a bunch of questions, and from the
answers we can probably figure out something sensible.

Does the Bluetooth PAN spec allow forwarding of multiple kinds of
packets (IP, IPv6, arp, etc?)?  Is this done by having a next-protocol
field somehow, like ethernet's 16-bit type field, similar fields in ppp,
or an AF word in tunnel drives?

What is the service model for NAP/GN/PANU users?  Do they see a
point-to-point link (logically), or a network with multiple hosts?
Specifically, is PANU A supposed to perceive PANU B as an attached peer?
Or is this all vague and PANU A is supposed to just default-route all
packets to the NAP/GN node?

How are addresses handled?  Are the semantics of bluetooth addresses
sufficiently close that it's possible for the tap interface to work with
bluetooth addresses with nothing bad happening?

Does the bluetooth spec involve using ARP to resolve IP addresses into bluetooth addresses?

When a PANU client sents a broadcast packet, is the same
ff:ff:ff:ff:ff:ff address used as in ethernet, and does this packet get
related to all other PANU clients on the same NAP/GN?  In other words,
is this like 802.11?

With tap, packets that arrive from the host will show up on the file
descriptor.  The daemon will then need to send this packet to the single
peer (PANU case) or all connected peers (NAP/GN) case.

When a packet arrives from the peer, sending it to tap will cause it to
be received or forwarded by the local stack.  That's an IP-level or
bridging-level action, and may or may not be what you want.  A packet
arriving at a NAP/GN should be sent to the correct peer, which could be
a single PANU, or all of them in the multicast/broadcast case.  If the
destination address is ours, or mc/bc, then it should be written to the
tap.

  What I'm uncertain about is, in my hazy vision of a btpand, I would
  have done that by cloning a new tap(4) for each session and let the
  system handle routing of packets. I think it would make btpand
  somewhat simpler, but does it work that way?

I'm not sure what you mean by session, but if you mean connection to a
peer, then it seems this isn't the right thing to do.

  Also, if that is the way to go, the Bluetooth Network Encapsulation
  Protocol (BNEP) which the PAN profiles use allows filtering on protocol
  types and/or according to multicast addresses. Can either one of these
  be passed off to the kernel?

I'm not sure, but first you need to define what you are trying to do
precisely.  Perhaps you know, but it seems the set of people who
understand bluetooth and those that understand the traditional stack are
disjoint.