I completely agree with @ben:
You can get working with using “close-enough” definitions, but that is building a house of cards, anytime you want to change something you will hit new difficulties. From my experience with “classic automation” companies’ software, this is the reason why things move so slowly.
PLR is all about enabling dynamically changing your automation setups… so that you can run real experiments, as opposed to run the same process over and over again, i.e. “process churning” (which it still can do, and is important, but now you can do more) 
Plate Definition
Let me make some new guides for generating novel plate definitions in PLR over the weekend.
In the meantime, I had a quick look into your plate: I think you are correct, Eppendorf part number 0030129334 (manufacturer link) is what you are working with.
Looking at the technical drawings there are some differences:
though not “too” massive, and most importantly the
material_z_thickness of the wells is pretty much the same.
(Note that neither is following the ANSI/SLAS 1-2004 Microplates - Footprint Dimensions standards, i.e. 127.76 mm × 85.48 mm (±0.5 mm))
But you found a flaw in the naming system here: You are correct, they should be named the same based on PLR’s current naming convention for plates (documentation link).
We briefly discussed this possiblity when we introduced it but deemed it unlikely to be an immediate issue… now it is an issue 
Do you (and @rickwierenga) think an additional “_<miscellaneous_descriptor>” would be useful here?
i.e. your plate would be called Eppendorf_96_wellplate_250ul_Vb_semiskirted?
I would like to try and avoid exact catalogue numbers in the definition name itself as it is quite error-prone and doesn’t give the user immediate information (you can see I tried this out with the Hamilton plate_adapter above a long time ago). The catalgoue number still has to be recorded in the docstring of the definition and the documentation pages, so other people can buy the exact item that is being defined.