I'm adding some things I have learned going through the collection about precautions and results based on information already provided and actual effort.
Many IMG and DSK files use resource forks and should not be unpacked even if you feel the need to unless you repack them on a classic or OS X environment on HFS+ or they could and/or mostly will not mount again. IMG and DSK files don't consistently mount or verify their integrity if at all when the host is using NTFS over extfs. They again must be copied over in this case, and again still archived as they were. Some IMG/DSK files that otherwise throw issues when you extract them against the warning I ignored may mount without issue on a native OS X platform using HFS+ (10.4.11/PPC) but most will not after you have gone this far.
Toast files don't appear to mount correctly using extfs until they are copied to the machine regardless of it they are over 4GB or not. Basillisk II/SheepShaver on Windows must use SLIRP, and as a result can't cross the network boundaries as it is hardcoded to run using the 10.0.2.0/16 netrange which prevents SMB/CIFS via DAVE 4.0 and AFP ability as well.
A crossover with a second dedicated ethernet adapter on the host will not necessarily work either, depending on the priority of the network devices and which one is chosen typically by the emulator. TUNTAP is supported on OS X though reports suggest some issues above 10.7 (Lion), but the selling point is that you gain the flexibility that allows one to get around many of these these issues as it virtualizes an interface, bridges another, and permits setting specific network information that otherwise would be fixed.
TUNTAP on FreeBSD and Linux platforms are unaffected by the reported issues. AFP support was removed in 10.6 when Apple made OS X Intel only, but other FOSS systems still bundle or provide Netatalk such as Slackware Linux as recent as 14.2. Using *NIX hosts with Netatalk behind the same switch despite different netmasks/ips will generally work even if the host itself is serving the os as a vm, so long as the guest network is in promiscuous mode, firewall permitting, to allow the flow of packets with varied source/destination routes and other typically permitted details, which aren't so much in a datacenter setting. The underlying filesystem where the share lies must be HFS+ due to the resource forks, and there are no promises that Samba or native NT file mappings will not destroy them just as on other platforms as a result of the transitive nature of the CIFS/SMB protocols which are designed to maintain compatibility with a range of systems unable to use HFS+ characters such as the colon.
In regards to the 3rd party AFP options formerly available on Windows, many vendors ceased development though coincidentally when Microsoft began encouraging secure mode via (U)EFI with OEMs just before the release of Windows 7 but also at the same time as Steve Jobs stated that Firewire was dead in 2008. In part the key signing requirements and inability to load unsigned drivers at the same time accelerated the decision for many OEMs creating drivers to give up on the effort. Other systems which implemented AFP/TCPIP as a userland process still work natively today, even though largely unchanged since that time.
Workarounds for Windows 7 and Windows Server 2008 users attempting to use older options not designed for their system or had expired signing certificates are similar to those which also needed to load other unsigned or experimental drivers when at time necessary while emulators such as Charon AXP+ or the former PS3 Sixaxis controller driver also have had to use insecure boot mode. As Microsoft has Services for UNIX, it previously had Services for Macintosh back in the NT 4.0 days. Microsoft gave up on Apple File protocol support in 2000 just after the release of 2000 Professional/Server but continued supporting it in Windows server 2003. Those systems while using the 2.2 version of the protocol can still provide this support under virtualization today without Kerberos/Active Directory support.  
For Windows users using older non-virtualized solutions, this has meant modifying the bcd (Using bcdedit itself or a tool such as easybcd, which abstracts the details of MBR vs EFI details itself just focusing on the needed changes to the flags) to permanently leave the system in development/unsigned mode, and then patch the shell32 dlls using the universal watermark removal tool or UWD to make it less apparent that the host system is in unsigned/developer mode.
Hosts booted into unsigned mode cannot play online with some modern games such as those employing Valve Anti-cheat (VAC), BattlEye (ARMA2/3), or EasyAntiCheat (Rust) due to the fact that kernel debuggers are not detected at the same level than is typically expected by the detection engine. As this causes a concern for the maintainers, the anticheat engines will then fail to initialize knowing the system isn't in secure mode, and then as a user you end up simply being unable to join any server that is protected by these measures. So if you need to do this, we should assume the machine is dedicated to running emulators for legacy operating systems or only computational tasks.
AFP shares hosted from a real machine (My G4 / 10.4.11) even when connected via the same switch in the same LAN did not solve the issue due to the network topology/broadcast issues. Connecting directly in any direction even though the host is technically aware of the vm did not work either and I didn't expect it to as subnets were created for the purpose of allowing more nodes to connect to a given network/range/network/domain/topology at the cost of isolating the others.
Most toast images can be converted to ISO and then be mounted by Basillisk II / SheepShaver directly, requiring a halt each time so they appear to be physically attached to the vm as the software can't do real-time changes to mounted devices. Archives in .bin, .bin.hqx, .sit.bin, etc. should be copied and extracted every single time from the host and on the vm itself. Converting the toast image to an iso/cdr will not magically fix the issue where it as mentioned can't be mounted using extfs. The remaining bugs trigger issues with the archivers, which then will throw "An unexpected error prevented mounting this volume" or similar.
This reply is mainly for those using Basillisk II or SheepShaver, but may also affect those running actual hardware in an environment that has similar constraints. While most of these issues can be worked around, the most aggravating of them all is that toast images cannot be mounted directly when using extfs to expose host mounts when the host format is NTFS or FAT32 by derivative limitation. The result is a worn out disk ruined before its time. Amusingly you will need a new mouse in any case after you get done organizing as the sheer volume of files will require thousands of clicks at minimal.
I hope this thread helps someone.