Reusability is a feature of good software design.
Is reusability an acceptable gloss ("brief notation of the meaning") for good software design? Why?
Reuse is an indicator of good design. It indicates that the coupling of the system is loose enough and the cohesion of a particular unit is high enough to facilitate reuse without running into dependency issues or having to rewrite most of the code.
Reusability is largely an illusion. It is verifiably impossible to measure the "reusability" of a unit without knowing in advance where or how it is going to be used. Many developers will try to design "reusable" components and often find out later that the specific aspects they tried to make "flexible" are exactly the ones which didn't need to be.
I would use a different "gloss": Testability.
Now I am not an advocate of TDD, nor do I feel the need to unit test anything and everything. But writing tests for a component will give you a very good idea of its coupling/cohesion characteristics, and very quickly. If it depends on abstractions, then that is loose coupling; you will find it easy to mock out the dependencies and that suggests a good design. If it has a clear purpose (see also Single Responsibility Principle) then its behaviour will be relatively intuitive, you will find it easy to figure out what to test, which again, suggests a good design.
That does not, of course, guarantee a good design; the actual implementation or even the whole architecture may be entirely inappropriate for its stated purpose. But at least it tells you that you are not working with spaghetti code or God Objects.
Please, do not try to make wild guesses as to the "reusability" of a component, especially not to use as evidence of "good design". That is something you can only establish in hindsight, once it actually gets reused, and by then the design may have changed significantly.
Reusability is a good feature to have, because it can speed future development. (Though in practice very few organizations see future development speeded by nearly as much as they hoped it would be.) However any significant piece of software has parts that are specific to that application. And furthermore when people without domain experience try to write reusable software, they usually obfuscate that piece and reduce performance without actually succeeding in making it reusable.
Therefore good design is modular, and reusable only where you can see that the piece can be reused, and where you have the expertise to actually achieve reusability. Elsewhere you should attempt to make things clean but don't worry about reusability. (Except in the back of your head where you're making notes so that on some future system you'll have an idea how to make that reusable.)
I belive (and this is my personal belief) that the relationship between reusability and good design is not reflexive, so the basic and simple answer is no. If you're interested on some good design guides, check this wikipedia article.
A good software design must be reusable, at least in some core parts, I think that very little people do actual reusing of source code, due to the fact that it's extremely complex to design the core of a system to be reusable at many different contexts (And I'm saying this out of experience)
Consider a class with a huge amount of responsabilities (a.k.a a Blob) performing all the tasks you need well but without any sort of design considerations at all, perhaps you've seen the case. Most people with a class like that would use it over and over and I think that we'll have to agree that it's reuse, designless reuse.
Hope I didn't mess my explanations too much
I think a better indicator of good design is adherance to fundamental ideas such as the single responsibility principle and maintaining cohesion of each component. By using abstractions with a clean and concise interface and maintaining compliance with the Liskov Substitution Principal we encourage reuse while not trying to predict what will and will not be reused.
Sticking to these fundamental design principles makes code easier to test and easier to reuse.
Good design == good design, reusability is a by-product.
Reusability is often an implicit design goal. If you can create a component, or an entire design, in such a way that it can be reused later, it seems obvious that you should do that. What's not always obvious is that it can take a lot of time and effort (and money) to make something reusable, and the benefit of reusability must therefore be weighed against its cost.
A reusable design that costs twice as much and/or takes twice as long to build than what the customer needs is not a good design from the customer's perspective, particularly if the customer doesn't need reusability.
There are a number of similar attributes that are often considered to be implicit design goals because they seem obviously good:
minimizing development time
These things are all objectively good, but may not always be important to a particular client at a particular time, so it's important to fully understand what your customer needs (even if that customer is just your boss). There are a number of aphorisms that are meant to remind us of this fact (e.g. "Done is better than perfect" and "Good, cheap, fast: pick any two"), but it's still easy to fall into the trap of trying to make software that's great in every respect when in fact great in every respect isn't always needed.
To get to the title question, then: No, reusability is not synonymous with good design. Reusability may be a useful component of a particular good design, but only when it's required.
Not necessarily. If you make something reusable that is clearly never going to be reused then that's bad design.
For example, if you are writing a file full of data which is unique to your company and that data is to be imported once to somewhere else, why bother making it reusable?
That said, if your framework doesn't have one already, the code to write to a file may need to be reusable. That would be good design.
I would say no, mostly because it only describes a small segment of code. I have found that where usability is most important is at the very core and at the outer edges of utility territory, not so much in between. I will give a few examples of things where I think reusability is a useful metric of quality design.
For the CRUD stuff that takes up 70-80% of most apps, I just do not think reusability is a valuable metric at all.