Someone who is self-taught or who learned to code via a different curriculum (say, one based around scheme like MIT's, or one based around javascript) naturally will think of object orientation in terms of something that a programmer implements, and will see prototype-based OO as easier to implement and easier to predict, since inheritance (particularly multiple inheritance) can quickly get complicated. But, this mandated curruculum based around strongly-typed compiled languages with class-based OO and a nearly ideological focus on the (mostly imaginary) benefits of inheritance has mass-produced students who are primed to think of class-based OO as the natural state of things rather than as a tool that is only sometimes appropriate.
In any prototype language, adding classes is trivial (it's just a matter of treating some objects as inviolate), and adding inheritance and even simple forms of multiple inheritance (if you have access to metatables / can override member lookup routines) isn't terribly difficult. The opposite is generally not true. But, again, this focus on class-based OO is largely not based on strategic thinking, but instead upon mechanisms designed to make sure large numbers of entry-level programmers are part of a specific monoculture. (This has succeeded: consider the proliferation of Java -- a language that is only very rarely an appropriate tool for any job.)
I think you should go forward with your decision. I think the foundational designs probably matter more: providing flexibility to those who desire either is a tremendously powerful thing.
See, I wouldn't want to add class-based OOP as I feel that would "soil" the language as one could just completely ignore the prototype aspects and use it as a class-based language.