There are several issues at play here, and you’re conflating them mightily. You really must keep straight exactly what OS version, DroboFS version, and connection protocol you’re using. That could be any of (10.6|10.7), (1.1.2|1.2), (AFP|SMB). You also need to be aware of how the Drobo supports the various protocols to know where the blame is - things like netatalkd, samba, etc.
The AFP issues are most definitely not Lion’s fault. The blame for that lands squarely on netatalkd and DRI. You may have yet another issue, but at this point most 10.7/1.2/2.0.3 issues are at least vaguely understood.
Cannot connect via AFP under Lion - “The version of the server you are trying to connect to is not supported” (10.7, 1.1.2, AFP)
FIX - Upgrade to firmware 1.2
Lion removed support for “DHCAST128” - mind you, this was deprecated in 2002, so it’s not like they yanked the rug out from under anyone. You can force Lion to use it again, but that’s just delaying fixing it until Apple removes it completely from the code - which could happen in 10.7.1 for all anyone knows. The only reliable solution is to upgrade the NAS to support authentication from more recent than 9 years ago.
Time Machine not working under Lion (10.7, 1.1.2, AFP)
FIX - Upgrade to firmware 1.2
When you upgraded to Lion, but did not upgrade the DroboFS firmware, you could connect but not run a Time Machine backup because netatlkd in firmware 1.1.2 did not support the encryption updates now required by Time Machine. Firmware 1.2 updates the netatalkd package to support this. Slowly though, as seen below.
Shares not mounting for AFP connections after 1.2 firmware update (10.6|10.7, 1.2, AFP)
FIX - Delete the “.Apple*” directories at the root of the share
When you updated the firmware 1.2, that included updates to netatalkd to enable Time Machine - but also changed the way netatalkd (and AFP connections by extension) did many things, especially folder listings and metadata storage. The issue of shares not showing up has been discussed in several active threads, and seems to go back to the netatalkd upgrade botching the conversion of several “.Apple*” databases it creates at the root of the share. Deleting those will cause netatalkd to recreate them from scratch, and the shares then mount normally. I’ve experienced this firsthand.
Poor performance for AFP connections with small files and lots of directory checks (10.6|10.7, 1.2, AFP)
FIX - Patience. lots of patience…
AFP performance has long been miserable with small files due to the way it handles metadata storage - quite simply, lots of updates to it take lots of time, whereas with a single large file it can make one metadata update and then blast bits across the network (for the programmers out there I’m assuming this is O(n) complexity - if not worse, depending on the data storage design). Now we have an additional issue in play where the method netatalkd uses to examine directories for size and changes is very, very slow - and that just makes the “lots of changes” case worse - which hits Time Machine like a brick. People have reported success leaving the backup to run for days, as excessive as that is. I don’t run Time Machine, so I can’t really comment, but I deeply sympathize and think DRI should be taken to task for this - if not sued outright.
Problems with SMB connections from Lion (10.7, 1.1.2|1.2, SMB)
FIX - Um, what problems?
Lion did replace the samba networking layer in Mac OS X with an Apple-created stack, and this has caused some issues - for instance, you can’t use Lion Server as a Primary Domain Controller. I haven’t seen any reports of SMB connections to NAS units like the DroboFS failing, however, and it works just fine here. SMB connections stores metadata differently, presents some filenames differently, and cannot be used for Time Machine, so it may not be a usable solution for many.