Because we're leveraging ID's in the first set of buttons that are input type button's, there were modifications to the javascript and the DOM elements to get both to work on the same page for example.
A new script using new id's for repeated elements like the two buttons (now as button tags), the results box (where the output and converted numbers show up after use), and the script was duplicated using the unique id's assigned to these new elements this time, allowing the dynamic behavior to persist without id's having the same name... which also de-validates the page. :(
The differences between using an input button and a button tag can be complex. Both are helpful in an enterprise level system, because an input facilitates a submit of a parent form element, and starts a call to the server if the form's method is get or post. A button tag element conversely would need javascript using onclick (often) to trigger a function that also submits the form via javascript.
Meanwhile a button tag can facilite nested content and media which an input can't do without a lot of css... sometime fairly verbose css is required to control input tags cross-browser. Additionally, buttons can trigger actions that don't need to hit the server, to change on-screen UI elements or displays of said elements for example. However, a button tag click even driven by a function, must be specified to make simulated click event and pass a confirmation to a dynamic site running asp or php etc. of a real user interaction - when these sites are heavily secured against robot/spider quasi-clicks. Thus in some systems the newer html5 button tag creates more work than the convenience of nested content and cleaner css.