Offtopic, but may I ask you if the HDRI image you used for the background in the example above can be freely downloaded somewhere?
Enigma responded quicker 
BTW, anyone know what exactly problem we have with anisotropic closures? As I understand, it very easy feature from mathematics point of view, we already have Incoming vector (I), geometric flat normal (Ng), smooth normal (N), output vector(out), pair of “ray differentials”, and any texture output at current point when surface closure evaluated. What else we need to make normal texture/anysotropic calcs, tangent vector and rest orthonormal? I am sure Brecht and other core developers very busy with Bmesh and Mango, better to make some patch and only then call them to fix/finish work.
The code is already there, using ward shader but its disabled in the code as it does not work, as you can see in the image below, my guess is either bad flipped tangents or improper use of tangents, having coded a ward shader for blender internal (using oldschool version shown here) i know how importan good tangents are
http://mfoxdogg.com/development/bad_gloss.png
you cna find the paper used of modern ward shader in OSL source files
Yes, Brecht said the holdup was the lack of proper smooth tangents. There aren’t proper dPds and dPdt derivatives calculated (or even available?) in the shader kernels, but I think that was it.
Not sure, but i “feel” that only problem is transform m_T from local barycentric triangle UV to actual texture UV. Trying to fetch UV from attribute, and recalc transform matrix assuming it linear inside triangle.
Yeah, since there are STs available on the triangle verts (somewhere!), given those there is a standard way to calculate tangents. Maybe I’ll try this out this week and see if I can get something to function. If not, I’ll hand off what I find to you storm_st so you can play with it.
That will be very good, i almost give up to grep that texture attribute ID chains, still cannot fetch real UV texture with offsets per triangle vertex, and just stuck at another namespace translator ShaderManager::get_attribute_id(). Maybe it is wrong way and I need to play with svm_node_attr_bump_dx() instead. Brecht comment out that closure for reason 
. But that Mitsuba Irawan cloth texture too attractive http://www.mitsuba-renderer.org/devblog/?p=163, as i understand we need same base vectors for that too.
Edit:
I think __device_inline void triangle_dPdudv(KernelGlobals *kg, float3 *dPdu, float3 *dPdv, int tri) is very promising, if we replace vertices geometry coordinates by actual (U,V,0), we get proper dPdudv with respect to UV space. So last step detect what attribute to fetch UV if present in mesh.
That would indeed be sweet if you two could poke the code a bit in this regard!