I can reproduce on tkagg and qt5agg (they both use the same renderer anyways so it'd have been a really weird bug if the result was different). This appears to be a regression somewhere between 1.5.0 and 2.0.0.
Bisecting is a pain because a bunch of commits in the middle appear to have completely broken alpha support :/

Well, here is my image using v2.0.0 using TkAgg:

And that is the same as the image I get using v2.0.1 and v2.1.0...

my though w.r.t. backends is more on the handling of the graphics context and whether or not the alpha gets passed around correctly. Doubtful, I know, but it is the only thing that made sense to me.

The only other possibility that I can think of is if the mpl_toolkits/mplot3d is getting picked up from someplace different than where matplotlib is and is running a different "version" of mplot3d even though different versions of matplotlib are getting tested?

$ MPLBACKEND=tkagg MPLCONFIGDIR=/tmp/mpld python -c 'from mpl_toolkits import mplot3d; print(mplot3d)'
<module 'mpl_toolkits.mplot3d' from '/home/antony/src/extern/matplotlib/lib/mpl_toolkits/mplot3d/__init__.py'>

This is my source tree where I have 2.0 checked out.

Can you confirm on your side?

For me, matplotlib and mpl_toolkits/mplot3d match up. They were installed via conda for the v2.0.0, v2.0.1, and v2.1.0 versions I checked.

This for the v2.0.0 install I have:

(hurricane) bash-4.2$ MPLBACKEND=tkagg MPLCONFIGDIR=/tmp/mpld python -c 'from mpl_toolkits import mplot3d; print(mplot3d)'
<module 'mpl_toolkits.mplot3d' from '/home/broot/scratch/miniconda/envs/hurricane/lib/python2.7/site-packages/mpl_toolkits/mplot3d/__init__.pyc'>
(hurricane) bash-4.2$ MPLBACKEND=tkagg MPLCONFIGDIR=/tmp/mpld python -c 'import matplotlib; print(matplotlib)'
<module 'matplotlib' from '/home/broot/scratch/miniconda/envs/hurricane/lib/python2.7/site-packages/matplotlib/__init__.pyc'>
(hurricane) bash-4.2$ ls -l /home/broot/scratch/miniconda/envs/hurricane/lib/python2.7/site-packages/mpl_toolkits/mplot3d/

And this for the v2.1.0 install:

bash-4.2$ MPLBACKEND=tkagg MPLCONFIGDIR=/tmp/mpld python -c 'from mpl_toolkits import mplot3d; print(mplot3d)'
<module 'mpl_toolkits.mplot3d' from '/home/broot/scratch/miniconda/lib/python2.7/site-packages/mpl_toolkits/mplot3d/__init__.pyc'>
bash-4.2$ MPLBACKEND=tkagg MPLCONFIGDIR=/tmp/mpld python -c 'import matplotlib; print(matplotlib)'
<module 'matplotlib' from '/home/broot/scratch/miniconda/lib/python2.7/site-packages/matplotlib/__init__.pyc'>

Ah, of course, Py2 (I can confirm it works there for me too).
So it's a Py3-only issue, probably some kwargs ordering...

The only possibility I can think of there is dictionary order... but we addressed those issues a long time ago, and usually that had to deal with the order of colliding properties...

Maybe the alpha of the default color is overriding the user's alpha (doubtful...)?

I just ran a small debugging check between Python 2 and Python 3 myself. And indeed I see that the key alpha in Python 2 remains the first key in kwargs, while in Python 3, alpha becomes the last key in kwargs (when zsort and facecolor are added into kwargs).

I am not familiar with how matplotlib handles kwargs with different key orders though. Just offering my observations. Hope they help.

And then I inserted this line

kwargs = {k: kwargs[k] for k in reversed(list(kwargs.keys()))}

immediately before this location (https://github.com/matplotlib/matplotlib/blob/master/lib/mpl_toolkits/mplot3d/art3d.py#L542), which simply created a new dictionary reversing the key order (so that alpha was the first key), and I was able to get semi-transparent 3D bars in Python 3.

Admittedly this is only a temporary hack. The matplotlib developers should be able to come up with a rigorous patch.

Alternatively, something like

diff --git a/lib/mpl_toolkits/mplot3d/axes3d.py b/lib/mpl_toolkits/mplot3d/axes3d.py
index 1bd3cf7c0..2ad640943 100644
--- a/lib/mpl_toolkits/mplot3d/axes3d.py
+++ b/lib/mpl_toolkits/mplot3d/axes3d.py
@@ -2529,8 +2529,8 @@ class Axes3D(Axes):
 
         col = art3d.Poly3DCollection(polys,
                                      zsort=zsort,
-                                     facecolor=sfacecolors,
-                                     *args, **kwargs)
+                                     *args, **kwargs,
+                                     facecolor=sfacecolors)
         self.add_collection(col)
 
         self.auto_scale_xyz((minx, maxx), (miny, maxy), (minz, maxz), had_data)

also fixes the issue. But note that both patches only work on Py3.6 as they rely on kwargs conserving kwargs order.

But it's really a problem of Poly3DCollection only updating the facecolors with the alpha if the alpha is already set when the colors are given (and the luck that on Py2, "alpha" comes before "facecolor" in dict iteration order...). Something like

p = ax.bar3d(0, 0, 0, 1, 1, 1); p.set_alpha(.5)

also fails to apply the alpha on Py2.

To follow up on the previous comment, bar3d passes the alpha to set_alpha,

For me with Python 3, p.set_alpha (where p is the Poly3DCollection object) also has no effect, so the issue is with this method IMO.

Internally, set_alpha mostly consists of,

Whereas using,

p._facecolors3d = matplotlib.colors.to_rgba_array(
                          p._facecolors3d, p._alpha)
p._edgecolors3d = matplotlib.colors.to_rgba_array(
                          p._edgecolors3d, p._alpha)

and combining it with the fix proposed in #4067 (comment) (I was getting the corresponding error anyway),

p._facecolors2d = p._facecolors3d
p._edgecolors2d = p._edgecolors3d

appears to make transparency work as expected.

Could be the same issue as #10237 for which there were already 2 attempted fixes, but none made it through yet. The one in #10487 looks promising and should just be a matter of getting merged?

Yes, I think this is a duplicate of #10237. The issue is ultimately with Poly3DCollection from what I saw. It's docstring states,

Note that this class does a bit of magic with the _facecolors and _edgecolors properties.

and some of that magic must not work as expected.

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

Appears to have been fixed by #13573 (at least that is what closed #10237, which this appears to be a duplicate of)