If it has the same version number as the referenced DLL, the GAC gets used.
If you increment the version number, rebuild the website referencing the new version number, put the new version in the /bin directory, then that DLL will be used.
If you do not want to change the version number, you're pretty much out of luck.
When .NET loads strong named assemblies, first it tries to decide what version number to use. It does this via the reference first, then it looks for publisher policies, then it looks for binding redirects in the configuration file.
After it does this, it looks for the assembly in the GAC, then in any codebase specified, then it probes various file system folders for the DLL. If at any one of those steps it finds the right version assembly, it stops.
If you are not changing the version number of your strong named assembly, .NET will find the original one in the GAC and stop looking. Note that because it stops when it finds one, and because looking in the GAC is first, specifying a codebase for your assembly will do no good unless you also specify a new version number.
Is it possible there are some controls on the OOTB master and not on your own master? Maybe there's a problem there. Furthermore, your custom master, does that also have a custom code-behind?
Best Answer
Essentially two things:
This allows SharePoint's full trust assemblies to make use of those operating under partial trust (yours).
Writing your own CAS file can be tricky and error prone if you want to do it properly. If you use a tool such as WSPBuilder it can create one automatically for you, which I strongly recommend. Otherwise, there's a written-by-hand guide here. A "cheat" method is to write a CAS file that fully trusts your assembly, but that's going against the point.
Note: Certain SP artifacts such as event handlers must be deployed to the GAC.