I was actually thinking more about the process of cognition of the Monad concept (the teaching and understanding framework), not about the Monad itself, and I was trying to say, that we should try to shift the attention to the a posteriori knowledge, as conceiving the noumenon of Monad is difficult, if not impossible, if it is described a priori and analytically. For example, when I was a young student, I was taught mathematics in a very abstract and axiomatic way (at the time when I was studying, Russian mathematical school was severely influenced by the Bourbaki group). It was really hard for me to get the real understanding or working knowledge of totally abstract ideas, expressed as a set of axioms (i.e., analytically). I basically started to understand the concepts many years later, when I started to use these concepts in a real life as a working engineer. So, I agree, that I extended the notion of Ding an sich a little bit further from the original Kantian definition. Though to myself, I’m envisioning all these dichotomies, like “thing in itself” vs “Thing for us”, “analytical vs. synthetic”, “abstract vs. concrete”, as categories connected with adjoint functors, that actually means that even reasoning about a monad is the monad. But seriously, we indeed can’t prefer abstract to concrete, or concrete to abstract, as neither is better than another, though what I’m seeing, especially in modern mathematics, is that there is a severe imbalance in the direction of abstraction, while the dual side doesn’t not get an equal attention.
With all these said, I totally agree, that the idea of conceptions can and should be used to illustrate the difference between a monad as an abstraction, vs. a monad as an implementation. However, abstraction has another duality - generalization. And I’m focusing on this dichotomy.
Concerning the Leibniz equality, it’s a funny coincidence, that I’m currently working on a hashconsing library that preserves the discernibility of structurally equal values, and trying to remove any notion of physical equality. The technical problem with physical equality, is that L 1 == L 1 is not always false, it is implementation specific, and can easily become true under flambda or other backend, such as bucklescript (and as a result of hashconsing optimization). That means, that we can’t rely on physical equality to distinguish between two drops of water, i.e., observably same objects in different place, as a compiler never took the responsibility to respect an object personal space.