I checked 36 GWC's and out of those some were dead, some still active, some unsure (these sites might not be configured for standard human contact.) Out of the unsure gwc's, 4 had websites but no indication of hosting and perhaps even totally unrelated topic websites (possibility of the domain being sold).

14 Dead
11 Unsure
11 Still active

I am still convinced at least one still active GWC (if I can call it active) is giving out-of-date information. Two of my BearShare connection lists (Win 8 + 2000) contain many hosts at top of the list from January but mostly from December and earlier (nearing a year old). One of my BS work lists is colour coded so a quick look to see when they were last seen (or a specific search for last exact date seen.) The Windows 8 list I started from scratch with just a dozen (or less) of active BS hosts a month or two ago. I was interested to see how it built up the list on its own.

Of course I have considered that I might simply not have seen such hosts and perhaps some of these hosts might still be active. However, I have major doubts that is the entire reason. The portion of the BS community that runs as peers does not seem to be dramatically large.
And then there's the occasional one I spot via another program that had not been seen before.

I do not like the way BS caches hosts locally. I have mentioned this before. And I suspect this contributes to the BS connection list going out of date fairly quickly. As examples, I can be connected to a host I've seen several times over a week or two but they are not to be found on the connection list. I can be connected to a host for a day or two, and they are not cached locally. I can be connected to a host who has an uptime of 6 days and they are also not to be found. I find myself manually adding hosts to the connection list. sighs
I also see decent reliable hosts rated lowly.
Perhaps this behaviour was limited to the BS 5.1 version, I don't know. But when the host list is only half-full and BS does not consider adding hosts for some unknown reason, it leaves me wondering and in no doubt why BS cache goes out of date fairly quickly.
The only logical reason I can think of why BS does not cache a host that has an uptime of 2-3 weeks and I've been connected to them for a few days is they are TCP firewalled. And thus not considered a worthy addition. This might happen if using BS 5.1 or earlier and not port forwarded which is a necessity. I doubt it is only a UDP firewalling issue as BS's UDP tests appear to fail rather frequently. ie: I've read whilst UDP is more bandwidth friendly, it is also known such UDP messages can get lost in transit rather easily. Not surprising when you consider the hammering hostile hosts give BS.
Edit 5 March 2014: Firewalled ultrapeers are not added/cached to the connection file. This is one reason many BS peers are not added to the connection file by BearShare itself. Those using BS 5.1 Beta must port forward the port they are using for both TCP & UDP or else, they will be firewalled. Other BearShare versions would simply not allow the program to become an ultrapeer if it were firewalled.

Auto Host 86.2x8.1x3.126:18335 ("gtk-gnutella/1.0.1 (2013-12-31; GTK2; Linux x86_64)") dropped: response code: 403 'Not a network member'. That's how GTK-Gnutella peers respond to firewalled BearShare 5.1 Beta ultrapeers! Handshake connection failed, communication between dropped.

I'd be curious to know where BS gets its local caching information from, other peers or gwc. ???
(It would not surprise me if the 5.2+ versions were deliberately designed to pass out bad connection caching data. Whatever the causes are, it is definitely a problem.)


Edit: 20 June 2013:

Host in x.x.x.x ("GNUCRAWL (crawl)") Replied to crawler.
-- Handshake 1 IN --
GNUTELLA CONNECT/0.6\r\n
User-Agent: GNUCRAWL (crawl)\r\n
X-Ultrapeer: False\r\n
Query-Routing: 0.1\r\n
Crawler: 0.1\r\n
\r\n

-- Handshake 2 OUT --
GNUTELLA/0.6 503 Full\r\n
User-Agent: BearShare 5.1.0b25\r\n
Peers: xx.x.x.x:6346,xxx.x.x.x:6348,…,...,.. etc.

So BS does communicate with such crawlers after all. (I was using Win 8 at the time, not one of its happiest days re: FW indication for UDP. BS had crashed before a reboot.)
It listed the peers then leafs I was connected to. Then 5 suggestive peers to try. One of these was a specific USA host address listed (not a range) on the Hostiles list. Hoorah. lol ... 20% failure rate. At least not as bad as GWC which tend to be saturated with hostile hosts. Some GWC's I've seen are really bad for such hosts. But as might have crossed your mind, the other 4 hosts suggested might have been proxy addresses, ie: possibility of a hostile crawler giving out bad data. The crawler itself was using a dynamic 24.x.x.x ip range. . (FYI all the 5 hosts used standard ports 6346 x2, 6348 x3. Germany, Poland, Belgium, USA x2)

Crawlers should be set up with both ip and port filters so they can be trusted.

Proxy addresses make it difficult. But I've had an idea for a long time, just wish I could program. They can be detected with the right tools and I've already posted such evidence on the forum quite some time ago where a proxy (hostile host) user was clearly shown with both their addresses. This is different to the standard gnutella protocol check for false/fake host addresses.