Point 2 is something that gets overlooked easily nowadays. I'd use even more specific types (or 'tiny types' as they're called sometimes), like MemberCompanyId, which could hold a Company instance and an Integer instance. Such members could be validated, i.e. checked for not null and for valid values (the id number could be forced positive, as an example). This will only allow to construct valid MemberCompanyId instances, and prevent any programming error caused by accidental deviations in input or state that create invalid objects.
Point 3: interesting and useful, I had never thought about it. I use varargs syntax quite often by the way, letting the caller pick what he wants to do with my code.
I find it kinda odd that a fundamental principle of OOP is information hiding, yet most mainstream languages make it a matter of pure discipline if you want to pass around a "CustomerId" instead of an "Int32" or alias any value type. In your own code it's not too bad, but there's constant conversions at api and library boundaries...
In general I lack the Smalltalk ideal of being able to subclass any type, like 'Int', call it something new and attach behaviour to it, while preserving API & DB compatibility.
Type aliasing in F#, ie `type Customer = int`, or discriminated unions with the same info, like `type CustomerId = CustomerId of int`, are wonderfully useful in that regard.
I also use "tiny types" a lot. In languages without any typing support (EG Javascript), I use ESDoc to write comments about expected types everywhere in my codebase, and I have a lot of `@typedef`'s, like `@typedef {string} CompanyID`.
I tried things like TypeScript and Flow, but I didn't get it working nicely with JSDoc or ESDoc. I want type-checking & generated docs, and I don't wanna define both twice.
Point 3: interesting and useful, I had never thought about it. I use varargs syntax quite often by the way, letting the caller pick what he wants to do with my code.