I believe this behavior is by design as NetBIOS works with broadcast packets. Setting up a WINS server when you set up the domain controller (and enabling the Computer Browser Service if it is Win2k8) and pointing clients to that WINS server should resolve this (assuming you have routing set up correctly).
WINS doesn't replace NetBIOS, but it provides a central point for NetBIOS name resolution that can work across subnets.
This depends on how those Samba servers are configured to handle the Username/UID and Groupname/GID mapping. This is done with the idmap directives. There are a couple of ways to configure Samba to handle this, but which one is in use will impact how they're able to handle cross-domain trusts and accounts migrating between domains.
The manual for this is here:
http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/idmapper.html
If they're using the default Winbind back-end, a database that matches Domain\Username pairs to local UIDs, when accounts migrate across domain boundaries they'll appear as new users to Samba. This is because their SID changes as they cross the domain boundary. However, this model does allow cross-domain usage over a trust.
If they're using the the RID back-end, the Samba server will NOT be able to allow access to users in different domains. If this is the case, you're probably already aware of it. When users move out of the domain the Samba server exists in, they will lose all access to it.
If they're using an LDAP server as a way to share Username/UID mappings across multiple Samba servers, the same restrictions as the default back-end apply. However, each Samba server will have the same Username/UID mapping. The upside is that you might be able to directly edit the LDAP server after migration to a new domain to ensure that the same Username/UID mapping is preserved.
The last option is perhaps your best bet for maintaining compatibility during your staged migration. However, if they're not already using an LDAP server as a central repository it will get much trickier.
Best Answer
The biggest drawbacks will be a lack of some features being supported and a lack of support for the configuration; you come asking why XYZ doesn't work and the moment you say you're using SAMBA for your domain and you'll have people sort of shrug it off and say that's the problem, whether it is or not.
You also run the risk of Microsoft's next service pack breaking something in the configuration.
You don't know when there are network issues if it's because of a bug in SAMBA or if it's a legitimate problem with your configuration.
In the long run, you're better off using actual Windows Server or the small business server edition (depending on licensing needs) for directory services and keeping Ubuntu as your file server, in my opinion. Nonstandard configurations can work and can work well, but only if you're willing to put in a lot of extra administration time to learning the ins and outs, staying on top of bug reports, and putting up with the extra maintenance it takes to run that nonstandard configuration.
In the sense of keeping an organization running with minimal headaches and being able to focus on other system issues then nine times out of ten I would go with the mainstream approach.